2016-05-12 22:31 GMT+03:00 Laine Stump <laine(a)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(a)yoctocloud.net