On Fri, Jun 08, 2012 at 09:26:35AM -0400, Dave Allan wrote:
> On Fri, Jun 08, 2012 at 10:04:31AM +0200, 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 virDomainInterfacesAddresses (okay, maybe
> > too many plurals) and returns a dynamically allocated array
> > of virDomainInterface struct. The great disadvantage once
> > this gets released, it's written in stone and we cannot change
> > or add an item into it. Therefore we might add a padding into
> > it - something like reserved for future use. On the other hand,
> > everything important is already there - what else we will want
> > to add? :)
> 
> How about returning an XML document instead of a struct?  We've been
> burned by structs in the past...

The answer isn't entirely clearcut. I think it depends on what we
envision the scope of the APIs to be. If we think this is strictly
limited to IP address discovery then I think a struct is satisfactory.
If we think we'll want to provide more details like type of NIC,
MTU size, etc, then we'd want an XML document.

Personally I think we should pretty strictly limit the scope of the
APIs to just IP address lists, leaving anything else upto general
purpose guest agents (eg Matahari like thing).

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

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

Reply via email to