On 05/16/2016 11:09 AM, Vasiliy Tolstov wrote:
2016-05-12 22:31 GMT+03:00 Laine Stump <la...@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.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
