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

Daniel P. Berrange berrange at redhat.com
Thu Sep 5 12:27:50 UTC 2013


On Wed, Sep 04, 2013 at 10:35:34PM +0800, Osier Yang wrote:
> On 04/09/13 03:13, 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.
> 
> Hm, yes, the MAC address returned by guest agent might not
> match what the domain config specifies. It reminds me something,
> both the leases file and snooping will returns the interface name
> like "vnetN", which is different with what guest agent returns (like
> ethN or emN). And since the MAC address from guest agent might
> be different with what domain config specifies, we have no way to
> convert it into the names in domain config. That says we will have
> different name styles for guest agent and the other two methods,
> which will need quite documentations to explain.

Such is life. We just have to document these naming limitations.

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