[libvirt] Need to re-work final "peer address" patches and re-push them
I reverted these three patches that introduced and enabled a "peer" attribute for type='ethernet' interface <ip> elements prior to the release of 1.3.4 with the intent of fixing/re-posting them after release, but forgot until today: https://www.redhat.com/archives/libvir-list/2016-April/msg01995.html I have patches for most of the bugs, but the one problem that still doesn't have resolution is the naming of the "peer" attribute. In my opinion, having the two address attributes named "address" and "peer" makes it ambiguous which address is for the guest side and which for the host side (especially since the attribute that has been named "peer" would be set to the "address" in the netlink command, and the attribute named "address" would be set to "peer" in the netlink command :-O). Since "address" is an existing attribute, and already used for the guest side IP address in lxc type='bridge' interfaces, it must remain as-is. In order to make it obvious that the new address is for the host side of the tap (or veth pair in the case of lxc), I propose calling it either "host", or "hostAddress", e.g: <ip address='192.168.123.43' host='192.168.123.1' prefix='25'/> or <ip address='192.168.123.4' hostAddress='192.168.123.1' prefix='25'/> (Vasiliy had suggested "hostPeer", but I dislike that, since it sounds like "the peer of the host", which is even more misleading). Can some of you normally-opinionated people weigh in on this? I don't like the feeling of making a unilateral decision :-) Also, I'm realizing that, although there was a patch to support setting the host-side address (hmm - "hostSide"? nah) for lxc type='bridge' interface, this is not at all useful, because anything plugged into a bridge should not have any IP on the side plugged into the bridge. The place where it would be useful for lxc would be (just as it is for qemu) with a type='ethernet' interface - the guest-side veth would have "address" and the host-side veth would have "hostAddress", and it would then properly work without needing a bridge (which I think is the entire point). Since lxc doesn't currently support type='ethernet', I think that initial support should be made for qemu only, and when type='ethernet is added to lxc, it can be made to support an IP address on both sides of the veth pair from the start. Lacking any useful responses, I'm thinking to update Vasiliy's patches to use "hostAddress" (and fix the other bugs I had found) and re-post them.
On Wed, May 11, 2016 at 11:57:36 -0400, Laine Stump wrote:
I reverted these three patches that introduced and enabled a "peer" attribute for type='ethernet' interface <ip> elements prior to the release of 1.3.4 with the intent of fixing/re-posting them after release, but forgot until today:
https://www.redhat.com/archives/libvir-list/2016-April/msg01995.html
I have patches for most of the bugs, but the one problem that still doesn't have resolution is the naming of the "peer" attribute. In my opinion, having the two address attributes named "address" and "peer" makes it ambiguous which address is for the guest side and which for the host side (especially since the attribute that has been named "peer" would be set to the "address" in the netlink command, and the attribute named "address" would be set to "peer" in the netlink command :-O).
Since "address" is an existing attribute, and already used for the guest side IP address in lxc type='bridge' interfaces, it must remain as-is. In order to make it obvious that the new address is for the host side of the tap (or veth pair in the case of lxc), I propose calling it either "host", or "hostAddress", e.g:
<ip address='192.168.123.43' host='192.168.123.1' prefix='25'/>
or
<ip address='192.168.123.4' hostAddress='192.168.123.1' prefix='25'/>
IMO "host" is better. After all it's an attribute of "ip" element so it's obvious we're talking about addresses here. Jirka
On Thu, 2016-05-12 at 09:58 +0200, Jiri Denemark wrote:
On Wed, May 11, 2016 at 11:57:36 -0400, Laine Stump wrote:
I reverted these three patches that introduced and enabled a "peer" attribute for type='ethernet' interface <ip> elements prior to the release of 1.3.4 with the intent of fixing/re-posting them after release, but forgot until today:
https://www.redhat.com/archives/libvir-list/2016-April/msg01995.html
I have patches for most of the bugs, but the one problem that still doesn't have resolution is the naming of the "peer" attribute. In my opinion, having the two address attributes named "address" and "peer" makes it ambiguous which address is for the guest side and which for the host side (especially since the attribute that has been named "peer" would be set to the "address" in the netlink command, and the attribute named "address" would be set to "peer" in the netlink command :-O).
Since "address" is an existing attribute, and already used for the guest side IP address in lxc type='bridge' interfaces, it must remain as-is. In order to make it obvious that the new address is for the host side of the tap (or veth pair in the case of lxc), I propose calling it either "host", or "hostAddress", e.g:
<ip address='192.168.123.43' host='192.168.123.1' prefix='25'/>
or
<ip address='192.168.123.4' hostAddress='192.168.123.1' prefix='25'/>
IMO "host" is better. After all it's an attribute of "ip" element so it's obvious we're talking about addresses here.
I like "hostAddress" better myself :) Is there any real chance the "prefix" attribute will need to be specified for the host as well? Because in that case we would clearly have to go with "hostPrefix", and using "host" instead of "hostAddress" would look quite ugly. -- Andrea Bolognani Software Engineer - Virtualization Team
On Thu, May 12, 2016 at 10:31:34AM +0200, Andrea Bolognani wrote:
On Thu, 2016-05-12 at 09:58 +0200, Jiri Denemark wrote:
On Wed, May 11, 2016 at 11:57:36 -0400, Laine Stump wrote:
I reverted these three patches that introduced and enabled a "peer" attribute for type='ethernet' interface <ip> elements prior to the release of 1.3.4 with the intent of fixing/re-posting them after release, but forgot until today:
https://www.redhat.com/archives/libvir-list/2016-April/msg01995.html
I have patches for most of the bugs, but the one problem that still doesn't have resolution is the naming of the "peer" attribute. In my opinion, having the two address attributes named "address" and "peer" makes it ambiguous which address is for the guest side and which for the host side (especially since the attribute that has been named "peer" would be set to the "address" in the netlink command, and the attribute named "address" would be set to "peer" in the netlink command :-O).
Since "address" is an existing attribute, and already used for the guest side IP address in lxc type='bridge' interfaces, it must remain as-is. In order to make it obvious that the new address is for the host side of the tap (or veth pair in the case of lxc), I propose calling it either "host", or "hostAddress", e.g:
<ip address='192.168.123.43' host='192.168.123.1' prefix='25'/>
or
<ip address='192.168.123.4' hostAddress='192.168.123.1' prefix='25'/>
IMO "host" is better. After all it's an attribute of "ip" element so it's obvious we're talking about addresses here.
I like "hostAddress" better myself :)
Is there any real chance the "prefix" attribute will need to be specified for the host as well? Because in that case we would clearly have to go with "hostPrefix", and using "host" instead of "hostAddress" would look quite ugly.
Both IP addresses are required to be in the same subnet and thus have the same prefix Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On Thu, 2016-05-12 at 09:41 +0100, Daniel P. Berrange wrote:
On Thu, May 12, 2016 at 10:31:34AM +0200, Andrea Bolognani wrote:
On Thu, 2016-05-12 at 09:58 +0200, Jiri Denemark wrote:
On Wed, May 11, 2016 at 11:57:36 -0400, Laine Stump wrote:
I reverted these three patches that introduced and enabled a "peer" attribute for type='ethernet' interface <ip> elements prior to the release of 1.3.4 with the intent of fixing/re-posting them after release, but forgot until today:
https://www.redhat.com/archives/libvir-list/2016-April/msg01995.html
I have patches for most of the bugs, but the one problem that still doesn't have resolution is the naming of the "peer" attribute. In my opinion, having the two address attributes named "address" and "peer" makes it ambiguous which address is for the guest side and which for the host side (especially since the attribute that has been named "peer" would be set to the "address" in the netlink command, and the attribute named "address" would be set to "peer" in the netlink command :-O).
Since "address" is an existing attribute, and already used for the guest side IP address in lxc type='bridge' interfaces, it must remain as-is. In order to make it obvious that the new address is for the host side of the tap (or veth pair in the case of lxc), I propose calling it either "host", or "hostAddress", e.g:
<ip address='192.168.123.43' host='192.168.123.1' prefix='25'/>
or
<ip address='192.168.123.4' hostAddress='192.168.123.1' prefix='25'/>
IMO "host" is better. After all it's an attribute of "ip" element so it's obvious we're talking about addresses here.
I like "hostAddress" better myself :)
Is there any real chance the "prefix" attribute will need to be specified for the host as well? Because in that case we would clearly have to go with "hostPrefix", and using "host" instead of "hostAddress" would look quite ugly.
Both IP addresses are required to be in the same subnet and thus have the same prefix
I see. My vote for "hostAddress" still stands though: since the XML describes the guest, all unqualified attributes refer to it by default, ie. "address" can in a way be considered a shorthand for "guestAddress". Using "hostAddress" fits nicely with that, but "host" IMHO doesn't. -- Andrea Bolognani Software Engineer - Virtualization Team
On 05/12/2016 04:41 AM, Daniel P. Berrange wrote:
Is there any real chance the "prefix" attribute will need to be specified for the host as well? Because in that case we would clearly have to go with "hostPrefix", and using "host" instead of "hostAddress" would look quite ugly. Both IP addresses are required to be in the same subnet and thus have
On Thu, May 12, 2016 at 10:31:34AM +0200, Andrea Bolognani wrote: the same prefix
If 20 year old memories serve me correctly, the local and remote side of a point-to-point link can be on completely different networks (and the simple experiment I was able to do with ifconfig just now showed that it accepts such a setup - see below). The entire point (haha) of a point-to-point link is that there is only a single IP at the other end (unless additional routes are setup), and even ARP isn't necessary (or even possible on some media, e.g. PPP). But as far as I've been able to figure out so far, it's a bit different when you set a peer IP address on an ethernet interface - the result of doing this is that the local IP is set as you'd expect, the POINTOPOINT flag isn't set (I haven't found any way to set this with an existing shell command), and the "direct" route that's added to the routing table is for the network of the *peer* address combined with the prefix (normally the direct route added for an ethernet is for the subnet containing the *local* address). For example, when I give this command: ifconfig p4p2_3 1.2.3.4 pointopoint 5.6.7.8 netmask 255.255.255.0 I end up with only a single new entry in the routing table: Destination Gateway Genmask Flags MSS Window irtt Iface 5.6.7.8 0.0.0.0 255.255.255.0 U 0 0 0 p4p2_3 ^^^^^^^^ (NOTE - *not* 1.2.3.0) I don't have anything connected for the other end, but when I "ping 5.6.7.8" (or "5.6.7.24"), I see ARP requests for 5.6.7.8 going out on p4p2_3.(If I set netmask to 255.255.255.255, it of course only ARPs for 5.6.7.8) So we've established that the local and peer addresses don't need to be on the same subnet. And since the guest-side will be seeing the 1.2.3.4 network as peer, it *could* have a different prefix (maybe the host side wants to see the guest as 5.6.7.8/32 (single host), but the guest wants to see the host as 1.2.3.4/8). So I think Andrea has a valid point (and maybe this is another indicator that the address info for the two ends should be in separate elements; definitely it shows that the guest side and host side should be allowed to have different prefixes). The place where this could be most useful is on an lxc <interface type='ethernet'>, where libvirt is able to do the IP config for both the guest and the host side of the veth pair. Rather than continue to spout off about it, I'm going to try and do some experiments over the next few days (in between [life]) and see what happens. Hopefully I can get back to the list within a day or two with something less speculative.
On Thu, May 12, 2016 at 10:31:34 +0200, Andrea Bolognani wrote:
On Thu, 2016-05-12 at 09:58 +0200, Jiri Denemark wrote:
On Wed, May 11, 2016 at 11:57:36 -0400, Laine Stump wrote:
I reverted these three patches that introduced and enabled a "peer" attribute for type='ethernet' interface <ip> elements prior to the release of 1.3.4 with the intent of fixing/re-posting them after release, but forgot until today:
https://www.redhat.com/archives/libvir-list/2016-April/msg01995.html
I have patches for most of the bugs, but the one problem that still doesn't have resolution is the naming of the "peer" attribute. In my opinion, having the two address attributes named "address" and "peer" makes it ambiguous which address is for the guest side and which for the host side (especially since the attribute that has been named "peer" would be set to the "address" in the netlink command, and the attribute named "address" would be set to "peer" in the netlink command :-O).
Since "address" is an existing attribute, and already used for the guest side IP address in lxc type='bridge' interfaces, it must remain as-is. In order to make it obvious that the new address is for the host side of the tap (or veth pair in the case of lxc), I propose calling it either "host", or "hostAddress", e.g:
<ip address='192.168.123.43' host='192.168.123.1' prefix='25'/>
or
<ip address='192.168.123.4' hostAddress='192.168.123.1' prefix='25'/>
IMO "host" is better. After all it's an attribute of "ip" element so it's obvious we're talking about addresses here.
I like "hostAddress" better myself :)
Is there any real chance the "prefix" attribute will need to be specified for the host as well? Because in that case we would clearly have to go with "hostPrefix", and using "host" instead of "hostAddress" would look quite ugly.
If there's any chance we'll need to get more data for the host side of the interface (that's not the case for prefix, though), we should rather use a subelement, something like <ip address='192.168.123.4' prefix='25'> <host address='192.168.123.1' .../> </ip> Jirka
On Wed, May 11, 2016 at 11:57:36AM -0400, Laine Stump wrote:
I reverted these three patches that introduced and enabled a "peer" attribute for type='ethernet' interface <ip> elements prior to the release of 1.3.4 with the intent of fixing/re-posting them after release, but forgot until today:
https://www.redhat.com/archives/libvir-list/2016-April/msg01995.html
I have patches for most of the bugs, but the one problem that still doesn't have resolution is the naming of the "peer" attribute. In my opinion, having the two address attributes named "address" and "peer" makes it ambiguous which address is for the guest side and which for the host side (especially since the attribute that has been named "peer" would be set to the "address" in the netlink command, and the attribute named "address" would be set to "peer" in the netlink command :-O).
Since "address" is an existing attribute, and already used for the guest side IP address in lxc type='bridge' interfaces, it must remain as-is. In order to make it obvious that the new address is for the host side of the tap (or veth pair in the case of lxc), I propose calling it either "host", or "hostAddress", e.g:
<ip address='192.168.123.43' host='192.168.123.1' prefix='25'/>
or
<ip address='192.168.123.4' hostAddress='192.168.123.1' prefix='25'/>
(Vasiliy had suggested "hostPeer", but I dislike that, since it sounds like "the peer of the host", which is even more misleading).
Can some of you normally-opinionated people weigh in on this? I don't like the feeling of making a unilateral decision :-)
Also, I'm realizing that, although there was a patch to support setting the host-side address (hmm - "hostSide"? nah) for lxc type='bridge' interface, this is not at all useful, because anything plugged into a bridge should not have any IP on the side plugged into the bridge. The place where it would be useful for lxc would be (just as it is for qemu) with a type='ethernet' interface - the guest-side veth would have "address" and the host-side veth would have "hostAddress", and it would then properly work without needing a bridge (which I think is the entire point). Since lxc doesn't currently support type='ethernet', I think that initial support should be made for qemu only, and when type='ethernet is added to lxc, it can be made to support an IP address on both sides of the veth pair from the start.
Lacking any useful responses, I'm thinking to update Vasiliy's patches to use "hostAddress" (and fix the other bugs I had found) and re-post them.
I'm not actually convinced your host/guest distinction actually matches what was being done with the peer attribute. First, off the virNetDevSetIPAddress change was doing the following - "address" attribute is mapped to IFA_LOCAL in netlink - "peer" attribute is mapped to IFA_ADDRESS in netlink What is the difference between IFA_LOCAL and IFA_ADDRESS you might ask ? You can see that in /usr/include/linux/if_addr.h comments: * IFA_ADDRESS is prefix address, rather than local interface address. * It makes no difference for normally configured broadcast interfaces, * but for point-to-point IFA_ADDRESS is DESTINATION address, * local address is supplied in IFA_LOCAL attribute. So we're setting the peer / IFA_ADDRESS to make point-to-point routing work correctly. In LXC containers, we set an IP address on the *guest* side of the interface, based on the 'address' attribute. The patches extended that by also setting the 'peer' address on the *guest* side. This is true regardless of the type of <interface> backend configured in QEMU machines, we set an IP address on the *host* side of the interface, based on the 'address' attributee. The patches extended that by also setting the 'peer' address on the *host* side. We only do this for type=ethernet backends. IOW, whether we set addresses on the host or guest side of the interface right now is being determined by whether we use QEMU or LXC. You can't say the existing 'address' attribute is either host or guest - it could be for either. Likewise the added 'peer' attribute is also either for host or guest address - and will *always* match the side used for the 'address' attribute. ie if 'address' was set on the host, then 'peer' would also be set on the host. So based on this understanding, I don't think your suggestion to try and distinguish 'address' as being a guest thing and 'peer' as being a host thing is actually correct. In fact I think that 'peer' name was in fact probably correct choice of naming. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|
On 05/12/2016 05:12 AM, Daniel P. Berrange wrote:
On Wed, May 11, 2016 at 11:57:36AM -0400, Laine Stump wrote:
I reverted these three patches that introduced and enabled a "peer" attribute for type='ethernet' interface <ip> elements prior to the release of 1.3.4 with the intent of fixing/re-posting them after release, but forgot until today:
https://www.redhat.com/archives/libvir-list/2016-April/msg01995.html
I have patches for most of the bugs, but the one problem that still doesn't have resolution is the naming of the "peer" attribute. In my opinion, having the two address attributes named "address" and "peer" makes it ambiguous which address is for the guest side and which for the host side (especially since the attribute that has been named "peer" would be set to the "address" in the netlink command, and the attribute named "address" would be set to "peer" in the netlink command :-O).
Since "address" is an existing attribute, and already used for the guest side IP address in lxc type='bridge' interfaces, it must remain as-is. In order to make it obvious that the new address is for the host side of the tap (or veth pair in the case of lxc), I propose calling it either "host", or "hostAddress", e.g:
<ip address='192.168.123.43' host='192.168.123.1' prefix='25'/>
or
<ip address='192.168.123.4' hostAddress='192.168.123.1' prefix='25'/>
(Vasiliy had suggested "hostPeer", but I dislike that, since it sounds like "the peer of the host", which is even more misleading).
Can some of you normally-opinionated people weigh in on this? I don't like the feeling of making a unilateral decision :-)
Also, I'm realizing that, although there was a patch to support setting the host-side address (hmm - "hostSide"? nah) for lxc type='bridge' interface, this is not at all useful, because anything plugged into a bridge should not have any IP on the side plugged into the bridge. The place where it would be useful for lxc would be (just as it is for qemu) with a type='ethernet' interface - the guest-side veth would have "address" and the host-side veth would have "hostAddress", and it would then properly work without needing a bridge (which I think is the entire point). Since lxc doesn't currently support type='ethernet', I think that initial support should be made for qemu only, and when type='ethernet is added to lxc, it can be made to support an IP address on both sides of the veth pair from the start.
Lacking any useful responses, I'm thinking to update Vasiliy's patches to use "hostAddress" (and fix the other bugs I had found) and re-post them. I'm not actually convinced your host/guest distinction actually matches what was being done with the peer attribute.
First, off the virNetDevSetIPAddress change was doing the following
- "address" attribute is mapped to IFA_LOCAL in netlink - "peer" attribute is mapped to IFA_ADDRESS in netlink
What is the difference between IFA_LOCAL and IFA_ADDRESS you might ask ? You can see that in /usr/include/linux/if_addr.h comments:
* IFA_ADDRESS is prefix address, rather than local interface address. * It makes no difference for normally configured broadcast interfaces, * but for point-to-point IFA_ADDRESS is DESTINATION address, * local address is supplied in IFA_LOCAL attribute.
So we're setting the peer / IFA_ADDRESS to make point-to-point routing work correctly.
In LXC containers, we set an IP address on the *guest* side of the interface, based on the 'address' attribute. The patches extended that by also setting the 'peer' address on the *guest* side. This is true regardless of the type of <interface> backend configured
in QEMU machines, we set an IP address on the *host* side of the interface, based on the 'address' attributee. The patches extended that by also setting the 'peer' address on the *host* side. We only do this for type=ethernet backends.
Yes, thanks for making me realize that - I had been treating the veth device pair as a single interface, and naively assumed (because I'd been unable to test it due to the peer attribute missing from the formatter output) that the pair was altogether treated as a single device for purposes of IP configuration. (chalk it up to my pre-history working on PPP, where the two ends of the link always agreed on what each others' addresses were). Still, I think it's wrong that <ip address='1.2.3.4'/> on qemu should set the IP address on the host side, and the exact same element in the same place in an lxc config should set the ip address on the guest side.Why be purposefully inconsistent between hypervisors when we don't need to (and when doing so could be the cause of even further divergence in the future)?
IOW, whether we set addresses on the host or guest side of the interface right now is being determined by whether we use QEMU or LXC. You can't say the existing 'address' attribute is either host or guest - it could be for either.
and that's what I don't like.
Likewise the added 'peer' attribute is also either for host or guest address - and will *always* match the side used for the 'address' attribute. ie if 'address' was set on the host, then 'peer' would also be set on the host.
So based on this understanding, I don't think your suggestion to try and distinguish 'address' as being a guest thing and 'peer' as being a host thing is actually correct. In fact I think that 'peer' name was in fact probably correct choice of naming.
I agree, if you're trying to exactly describe what's happening at the lowest level of the configuration of each individual device. But if you look at it from a functional point of view, you have a single link with an IP address at both ends, and want to configure both of those addresses. At the lower level, the link is implemented with two devices not one (one on host , one on guest), and you almost certainly want to configure the two devices such that guestPeer == hostLocal and guestLocal == hostPeer (since it otherwise won't work properly). (MB: my understanding/opinion of this has changed slightly since considering Andrea's question about differing prefixes for host and guest sides - see my response in that sub-thread) In the case of LXC: (link handled by veth driver) guest veth <============================> host veth We can configure both of these devices in libvirt's setup code because libvirt creates both devices prior to starting the container, although currently we only configure the guest-side veth because the host side is always attached to a bridge, and you don't need/want an IP address on a device connected to a bridge (it's assumed of course that devices *beyond* the bridge-attached veth will have an IP address). If we wanted, though, we could set the IP address of the host-side veth, which would be useful in case of <interface type='ethernet'> (if that were supported on lxc, which currently isn't the case). qemu is more problematic though: (link handled by qemu or vhost-net) guest emulated NIC <========================> host tap Since the NIC device in the guest has no visibility to the host (it doesn't exist until qemu is started, and is only configurable by the guest OS), libvirt can only reasonably configure the host side tap device. (I suppose we could run a dnsmasq listening on the tap that could answer dhcp queries from the guest, or maybe add the capability to set guest-side IP addresses via a guest agent (or maybe even run PPPoE on host and guest, thus creating another level of devices :-O), but at present for all practical purposes the best we can do is simply hope that the guest-side IP configuration we can't controll matches/mirrors the host side configuration that we can control.) 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. 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.) 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> (the ip element under "source" would be used to set the ip address on the host side. As an aside, it would have made more sense to have this IP address specified in the same place as the host-side device is named, but for some odd reason it is named in the <target> element, which has come to be the place where attributes pertaining to how the device appears on the *guest* side live :-/).
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...
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.) 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>
(the ip element under "source" would be used to set the ip address on the host side. As an aside, it would have made more sense to have this IP address specified in the same place as the host-side device is named, but for some odd reason it is named in the <target> element, which has come to be the place where attributes pertaining to how the device appears on the *guest* side live :-/).
-- Vasiliy Tolstov, e-mail: v.tolstov@yoctocloud.net
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='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.
participants (5)
-
Andrea Bolognani -
Daniel P. Berrange -
Jiri Denemark -
Laine Stump -
Vasiliy Tolstov