Re: [PATCH 0/7] Introduce API for dumping domain IP addresses

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Jun 08, 2012 at 06:13:43AM -0600, Eric Blake wrote:
> On 06/08/2012 02:04 AM, 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.
> 
> How hard would it be to wire this API up to _also_ have the option of
> using our nwfilter IP learning code (first packet detection mode has
> been here for a while, and DHCP snooping mode was just added)?  Use of
> the flags parameter should make it possible to force which method we
> attempt, use of flags==0 chooses the best method possible (GA if
> present, otherwise fall back to nwfilter IP learning).

Yes, we should do this in the same way we handled the virDomainShutdown
and virDomainReboot APIs

 enum {
   VIR_DOMAIN_INTERFACE_ADDRS_DEFAULT,
   VIR_DOMAIN_INTERFACE_ADDRS_GUEST_AGENT,
   VIR_DOMAIN_INTERFACE_ADDRS_ARP_SNOOP,
   VIR_DOMAIN_INTERFACE_ADDRS_DHCP_SNOOP,
 }

> > 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? :)
> 
> But that's why we invented virTypedParameter.  If you would return an
> allocated array of virTypedParameter instead of a hard-coded
> virDomainInterface struct, then you have the flexibility to add new
> named parameters down the road without ABI concerns.  I haven't looked
> closely at your proposal yet, but just reading this one paragraph makes
> me think we need to rework it into using typed parameters.

Hmm, yes, using virTypedParameter could be quite a nice way to
make this more flexible, without going all the way to using a
XML document.

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@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list


[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]