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

Osier Yang jyang at redhat.com
Wed Sep 4 14:35:34 UTC 2013


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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20130904/188a1a4b/attachment-0001.htm>


More information about the libvir-list mailing list