Re: [libvirt] [PATCH 4/5] conf: Allow usernet to have an address

On 09/12/2017 05:53 AM, Martin Kletzander wrote: In order to be consistent between all different hypervisors and interface connection types, any ip addresses and routes that are set to be visible on the host side of the interface "apparatus" must be under <source>, and those that are set to be visible on the guest side must be directly under the top level of <interface>. Since the IP you're configuring in this patch will be seen in the guest, it needs to be at the toplevel (i.e. it will be parsed into net->guestIP). When I dropped into this code to add support for specifying the IP address and routes on the *host* side of a tap device/veth device (see commit 98fa8f3ef) for QEMU and LXC (along with the "peer IP" for the other end of a tap/veth, which is *not* the same thing!), I *wished* that we had added the new <ip> and <route> elements for specifying guest-side <ip> and <route> under <target> as you suggest, since <target> is intended to contain items configuring how the device appears on the guest side[*]. Unfortunately, the decision on the location of guest-side <ip> was made *long* ago (at least prior to July of 2008, I didn't feel like spelunking any further), when <ip> was added directly under <interface> to support setting the guest-side IP address on Xen. Many years later (2014), when cbossdonnat added support for setting the guest-side IP of  an LXC veth pair, he also used the same element in order to provide consistency. So, we are unable to put it under <target>, and that decision was made sometime befor 2008, [*] Of course, the <target> element is used inconsistently within <interface> when compared to other uses - <target dev='blah'/> is used to specify the name of the tap/macvtap device *as it is known on the host side*. <target> has been described to me as a place to configure what things look like to the guest (e.g. the intended name for a disk device on the guest)(which is anyway ignored everywhere except Xen, but that's a different topic!), so using it to configure a name that's visible only to the host seems wrong, but it's been that way since sometime long before even I was involved with libvirt, so there is no changing it now :-P I think it *would* have been good under <target>, if anyone had foreseen the need for a <target> grouping (and consistently used it) from the beginning. But that train sailed into space long ago, so in order to be backward compatible and consistent, the guest-side IP/routes need to be directly under <interface> (just like the guest-side PCI address for PCI devices is), and the host-side IP/routes need to go under <source> (just as host-side PCI addresses of <hostdev> devices are). That's good, because I *do*! :-P This will of course need to be rewritten (and grammar cleaned up). You realize now that you've added support for setting the IP address, inevitably someone will expect you to write patches to support setting of the DHCP server, DNS server, default route, DHCP range, hostname, NMBD server, domain name, tftp directory and bootfile,.... :-O) Or maybe just check for presence of <route> during parsing and issue an ENOTSUPP log if it's found (that will be needed anyway in case XML validation is turned off). There's a certain point of detail when we stop caring about the exactness of the RNG. Eventually it becomes more difficult to read the RNG than it's worth, and the error messages provided when validation fails. Yeah, this should be separated. It was previously combined for brevity, only because the two were both only supported in exactly the same cases. Also, it looks like qemu only supports a single IPv4 and single IPv6 address on each interface, so you need to validate there is at most one of each type.