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

[Nehal J Wani]

On Wed, Sep 4, 2013 at 8:05 PM, Osier Yang <jyang at redhat.com> 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.
>
> 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
>
>

Daniel, would like to throw some light on the discussion?

-- 
Nehal J Wani