[libvirt] [PATCHv2 4/5] interface: add virInterfaceGetXMLDesc() in udev

[Laine Stump]

On 10/09/2012 12:22 PM, Eric Blake wrote:
> On 10/06/2012 01:20 PM, Doug Goldstein wrote:
>> Added support for retrieving the XML defining a specific interface via
>> the udev based backend to virInterface. Implement the following APIs
>> for the udev based backend:
>> * virInterfaceGetXMLDesc()
>>
>> Note: Does not support bond devices.
>> ---
>> ***
>> * NOTE: I'm aware this is incomplete (e.g. no bond support) and we aren't
>> *       showing devices in a bridge. This patch can be considered only a RFC
>> *       or it can be applied and I'll work on further support as I figure
>> *       out how to implement it. Waiting for feedback from LKML and from
>> *       the udev ML on some questions or patches.
>> ***
> I'd rather let Laine also chime in on this one before it gets pushed (or
> decide that we need to wait for a v3), but my cursory review didn't find
> any major problems.
>

I just now saw this comment (my libvirt mail has been a bit out of
control lately).

My opinion of this backend is that there are two dangers here that we
need to avoid:

1) (I began encountering this one while answering some of Doug's
questions on IRC) For much of the functionality required for an
interface driver backend on a Linux distro, the exact code that you
would end up putting into your own back end has already been implemented
in netcf, so you could end up duplicating a lot of code (and bugs), with
the associated headaches.

2) After a certain point, the amount of time/energy spent
re-implementing the same functionality in a different driver becomes
greater than the amount of time it would have taken to just bite the
bullet and do a netcf port.

(On the other hand, it's a useful exercise in working out the kinks in a
generalized interface driver interface)

Actually it occurred to me just a couple nights ago that this effort
might have been spent making a port of netcf that used udev to get the
device list, rather than an alternative interface driver for libvirt;
this would probably take about the same amount of effort, and the result
would be a partial-featured "universal Linux" port for netcf.

Where am I going with all of this? Well, I think the best implementation
of this driver is the simplest one that provides enough information to
satisfy your particular needs, and as I understand it that is to allow
virt-manager to get a list of network devices and their types, to be
used for a drop-down list of guest network connection options. Once you
go beyond that, you're duplicating code (e.g., to get the ip addresses
of an interface, you either have some ugly hack that calls the "ip"
utility, or you write pretty much the same hunk of libnl calls that are
already in netcf). At some point, I think it's best to give in and just
make a netcf port for your distro (then you'll also gain things like
"virsh bridge eth0 br0").

(BTW, something that I just thought about now - does this driver
differentiate at all between transient and permanent bridge/vlan
devices? Historically netcf has only listed devices that are permanently
in the systems configuration, but not anything that is temporary (e.g.
the virbrX bridges created for libvirt's virtual networks).)