[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On 05/16/2016 11:09 AM, Vasiliy Tolstov wrote:
2016-05-12 22:31 GMT+03:00 Laine Stump <laine 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='' peer='' prefix='8'/>
         <source ..... >
            <ip address='' peer='' prefix='32'/>

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='' peer='' prefix='8'/>
        <route address='' prefix='24' gateway=''/>
        <source ..... >
           <ip address='' peer='' prefix='32'/>
           <route address='' prefix='8' gateway=''/>

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.


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]