[libvirt] Need to re-work final "peer address" patches and re-push them

[Laine Stump]

On 05/16/2016 11:09 AM, Vasiliy Tolstov wrote:
> 2016-05-12 22:31 GMT+03:00 Laine Stump <laine at laine.org>:
>> To come back to the point:
>>
>> 1) libvirt attempts to provide the same end-result (or as close as possible)
>> for all the hypervisors for any given configuration; I think that having <ip
>> address='blah'> set the guest-side local IP on one hypervisor, and the host
>> side local IP on another doesn't live up to "as close as possible". Those
>> are different entities, and should be configured separately.
>>
> Yes, that does matter. May be in the feature we want to start dnsmasq
> on this tap device...

Right. What I was thinking of is that dnsmasq could be started answering 
only queries from the MAC address given in the interface config, and 
offering the IP address given in <ip>. This wouldn't scale very well, so 
we might want to have a single dnsmasq instance for all type='ethernet' 
interfaces that require it, and just restart it any time and guest is 
started or stopped (assuming that dnsmasq would complain if an interface 
it was explicitly told to listen on didn't exist).

I'm curious exactly how you hand-configure the guests now. Can you 
provide an example of what address/peer/prefix you configure for both 
the host side and the guest side? Also, routes, if any.



>> 2) It may be possible that there are valid configurations where guestPeer !=
>> hostLocal orguestLocal != hostPeer; such a thing doesn't come to mind at the
>> moment. If not, then having dual config so that all 4 can be represented
>> seems like overkill. (I'm going to try some experiments with this after I'm
>> done typing.)


I made a patch to support type='ethernet' on LXC over the weekend (I 
would add in a link to the email, but the mailing list server is somehow 
broken, so nothing in the last 2 hours has made it to the archive) and 
played around with it a bit by using ifconfig both inside the container 
and on the host. I found that, while it was most useful to set 
prefix='32', it was also possible to set differing prefix on either side 
(which could be useful in combination with proxy arp), and while (again) 
I can't think of a concrete reason why I would want to do it, if you 
were running proxy arp on one side or the other, it's possible to come 
up with a working configuration where guestPeer != hostAddress or 
guestAddress != hostPeer. Also, there could be situations where someone 
wanted libvirt to take care of all the IP address/route setup on one 
side, but leave the other side alone.


>> If we do decide that it is overkill, then rather than changing
>> the semantics of <ip> based on which hypervisor we're using, I think it
>> would be better that the address attribute of <ip>, which currently has
>> meaning only for lxc and means "the local-side IP of the guest interface"
>> should continue to have that meaning when support for setting IP addresses
>> for qemu is added.
>>
>> 3) If we do want to configure the host-side local and peer addresses
>> separately from the guest-side, then we could consider this:
>>
>>          <ip address='1.2.3.4' peer='4.3.2.1' prefix='8'/>
>>          <source ..... >
>>             <ip address='4.3.2.1' peer='1.2.3.4' prefix='32'/>
>>          </source>

My thinking on this after a very small amount of experimenting - it is 
tempting to try and reduce the amount of config elements by saying, e.g. 
"guest and host prefix are always the same", or "guestPeer always == 
hostPeer" etc, but that almost always leads to regret later. Maybe that 
could be the *default*; possibly the best patch is to just support the 
full complement in config, adding <route> into the mix:


         <ip address='1.2.3.4' peer='4.3.2.1' prefix='8'/>
         <route address='192.168.122.0' prefix='24' gateway='4.3.2.1'/>
         <source ..... >
            <ip address='4.3.2.1' peer='1.2.3.4' prefix='32'/>
            <route address='10.20.1.5' prefix='8' gateway='1.2.3.4'/>
         </source>

The <ip> and <route> elements inside <source> will set the IP 
information and add routes for the host side device, and those at the 
top-level will set IP and add routes for the guest side device. This 
will be the same whether it is LXC or QEMU.

The downside of this method is that the general use case (for LXC 
anyway) would require nearly duplicate address information for the two 
sides (routes would be different). On the other hand, we won't get stuck 
in the trap of making a wrong assumption of how everybody is ever going 
to use it, thus making it unusable for somebody someday.

Opinions?

I'm going to start on the XML parsing/formatting for this this afternoon.