[libvirt] [PATCH v2 0/5] Introduce API for dumping domain IP addresses

[Daniel P. Berrange]

On Tue, Jul 31, 2012 at 11:22:09AM +0800, Daniel Veillard wrote:
> On Mon, Jul 30, 2012 at 12:59:27PM +0200, Michal Privoznik wrote:
> > On 21.06.2012 15:55, Michal Privoznik wrote:
> > > This feature has been requested for a very long time. However,
> > > we had to wait for guest agent to obtain reliable results as
> > > user might create totally different structure of interfaces than
> > > seen from outside (e.g. bonding, virtual interfaces, etc.).
> > > That's the main reason why sniffing for domain traffic can
> > > return bogus results. Fortunately, qemu guest agent implement
> > > requested part for a while so nothing holds us back anymore.
> > > 
> > > To make matters worse, guest OS can assign whatever name to
> > > an interface and changing MAC inside guest isn't propagated
> > > to the host which in the end see original one.
> > > 
> > > Therefore, finding correlation between interface within guest
> > > and the host side end is left as exercise for mgmt applications.
> > > 
> > > This API is called virDomainGetInterfacesAddresses (okay, maybe
> > > too many plurals) and returns a XML document containing all
> > > interesting data.
> > > 
> > > diff to v1:
> > > -switch from struct to XML doc
> > > 
> > > Michal Privoznik (5):
> > >   Introduce virDomainGetInterfacesAddresses API
> > >   virsh: Expose virDomainGetInterfacesAddresses
> > >   qemu_agent: Implement 'guest-network-get-interfaces' command handling
> > >   qemu: Implement virDomainInterfacesAddresses
> > >   python: create example for dumping domain IP addresses
> > > 
> > >  docs/schemas/interfaces.rng   |   57 +++++++++++++++++
> > >  examples/python/Makefile.am   |    2 +-
> > >  examples/python/README        |    1 +
> > >  examples/python/domipaddrs.py |   62 +++++++++++++++++++
> > >  include/libvirt/libvirt.h.in  |    2 +
> > >  src/driver.h                  |    4 +
> > >  src/libvirt.c                 |   49 +++++++++++++++
> > >  src/libvirt_public.syms       |    1 +
> > >  src/qemu/qemu_agent.c         |  135 +++++++++++++++++++++++++++++++++++++++++
> > >  src/qemu/qemu_agent.h         |    2 +
> > >  src/qemu/qemu_driver.c        |   68 +++++++++++++++++++++
> > >  src/remote/remote_driver.c    |    1 +
> > >  src/remote/remote_protocol.x  |   12 +++-
> > >  src/remote_protocol-structs   |    8 +++
> > >  tools/virsh.c                 |   41 ++++++++++++
> > >  tools/virsh.pod               |    9 +++
> > >  16 files changed, 452 insertions(+), 2 deletions(-)
> > >  create mode 100644 docs/schemas/interfaces.rng
> > >  create mode 100644 examples/python/domipaddrs.py
> > > 
> > 
> > Ping?
> > 
> > So do we have a consensus on this? The first version expose guest IP via
> > public struct, while this one returns an XML doc. Which one should we
> > prefer?
> 
>   It seems to me people suggesting either ways
>    1/ struct if we just return the IP adress[es]
>    2/ XML if we want to expand all the other informations about the
>       interface
> 
> At this point I would think we are not really in a good situation to
> extract and expose all the interface settings as seen from the guest
> and as Dan said it's more something to be done on the guest agent,
> that interface is a backup in the absence of agent or a way to bootstrap
> communication with the guest. I think v1 does this fine, though I would
> agree with Eric feedback on the API changes, I would also suggest -1
> as being the error failure code for this API.
> Then later if we can get full client interfaces viewpoint, as seen from
> the guest (is there an API for this in VMWare, we ought to be able to do
> it for LXC) then providing a second extensible API returning an XML
> could be added, but I think the core API need now it be able to easilly
> extract the IP(s) of the guest, and XML while being more flexible for
> future use would get in the way.
> 
>   So my take would be to refine v1, and based on feedback of v1,
> availability of informations in various drivers, then provide an
> XML extensible version if there is a need and a good way to provide
> the full information set.

I think I've already mentioned I had  a preference for v1 struct approach.
If we did go for th v2 XML approach, then I'd want us to align with the
virInteface XML schema for reporting interface configuration, instead of
creating a new schema.

FWIW, I don't think it would be the end of the world if we added a
struct based API now, and then *also* added a XML based API at a
later date (should it become required)

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