On Thu, 2016-05-12 at 09:58 +0200, Jiri Denemark wrote: 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, 2016-05-12 at 09:41 +0100, Daniel P. Berrange wrote: 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 Thu, May 12, 2016 at 10:31:34 +0200, Andrea Bolognani wrote: 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 05/12/2016 05:12 AM, Daniel P. Berrange wrote: 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)? and that's what I don't like. 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 :-/).

On 05/16/2016 11:09 AM, Vasiliy Tolstov wrote: 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. 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. 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.