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