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