[libvirt] [PATCHv5 1/5] domifaddr: Implement the public APIs
Daniel P. Berrange
berrange at redhat.com
Thu Sep 5 12:26:56 UTC 2013
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 :|
More information about the libvir-list
mailing list