Re: [PATCHv5 1/5] domifaddr: Implement the public APIs

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

 



On Tue, Sep 03, 2013 at 01:13:20PM -0600, Eric Blake wrote:
> On 09/03/2013 01:07 PM, Eric Blake wrote:
> > On 09/01/2013 07:43 AM, Nehal J Wani wrote:
> >> Define a new API virDomainInterfaceAddresses, which returns
> >> the address information of a running domain's interfaces(s).
> >> If no interface name is specified, it returns the information
> >> of all interfaces, otherwise it only returns the information
> >> of the specificed interface. The address information includes
> >> the MAC and IP addresses.
> >>
> >> Define helper function virDomainInterfaceFree, which allows
> >> the upper layer application to free the domain interface object
> >> conveniently.
> >>
> >> The API is going to provide multiple methods by flags, e.g.
> >>
> >>   * Query guest agent
> >>   * Parse lease file of dnsmasq
> >>   * DHCP snooping
> >>
> >> But at this stage, it will only work with guest agent, and flags
> >> won't be supported.
> > 
> > That worries me a bit.  Ultimately, we want our interfaces to behave as
> > sane as possible when flags==0; rather than making the behavior be that
> > 'flags==0' implies 'only guest agent probe', I'd rather introduce a flag
> > right away up front that says 'include guest agent probe in the set of
> > attempted methods', and then document that 'flags==0 is shorthand for
> > letting the hypervisor choose the best method(s) out of supported
> > possibilities)'.  In other words, I want to make sure that this API will
> > be similar to virDomainShutdownFlags, where a flags of 0 lets the
> > hypervisor choose between methods, a single explicit flag forces the
> > hypervisor to use that method alone, and more than one flag can be OR'd
> > together to let the hypervisor choose among that subset of flags.
> 
> Hmm.  I'm replying to myself - is that a good sign?
> 
> If the guest agent returns names that are provided by the guest, and
> don't necessarily correspond to the domain XML, then maybe it's best to
> NEVER return guest results by default, but to make the user always
> explicitly request agent interaction.  That is, even if 'flags==0' is
> used to select between parsing the lease file vs. DHCP snoop results
> (both of which tie perfectly to guest XML naming), the agent approach
> can seriously confuse users if they passed flags==0 and don't know if
> they are getting XML names or guest-provided names.  Which argues that
> guest results should ALWAYS be an explicit non-zero flag, never an
> automatic action.

Yes, that sounds like a good idea. The other reason to return DHCP
snoop results by default is that those will work for any guest
without requiring an agent installed.

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@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]