[libvirt] Need to re-work final "peer address" patches and re-push them

[Daniel P. Berrange]

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 :|