On 10/03/2018 04:23 PM, Cole Robinson wrote: > Hi all, > > I'd like to remove the <interface> object UI from virt-manager. This > is Edit->Connection Details->Interfaces, the bits that allow > starting/stopping/deleting/creating host network interface > configurations like bridges, bonds, vlans, and ethernet/wifi configs > > https://imgur.com/a/iyYXawV > https://imgur.com/a/lGO4QZ0 > > Long story short 1) I don't think this UI makes sense to have in > virt-manager, 2) no one seems to be using it. > > Most of this UI was added about 8.5 years ago to virt-manager. It has > mostly been unchanged since. At the time it seemed kind of compelling > that we could use the UI to create a host bridge device. However this > never quite 'just worked' often due to interference with > NetworkManager which really only learned to handle bridges in 2014ish > (even now I don't think it 'just works'). Since that time > nm-connection-editor provides a much more advanced UI for configuring > host network interfaces of all types. > > virt-manager's UI supports a lot more than just creating bridges > though, basically covering the entire <interface> schema in libvirt: > so configuring ipv4 and ipv6, various bond modes, etc. However no one > uses it. I'd bet good money that there's been 0 non-virt-developer > users of the 'Create Interface' wizard for something other than bridge > creation. Actually the largest use I've seen of virt-manager's Interface API support is from people who misunderstand that it is for managing *host* interfaces, and instead believe that they need to create one of these interfaces for each guest, and then when they can't, they mistakenly believe that guest networking is broken (this happened on IRC just a week or two ago). It is made worse by: 1) some distros using the udev backend for the interface API, which only supports reporting *currently active* devices (not device configurations) 2) Arch Linux apparently has a "port" of the netcf package (the other backend for the interface API) which was made by simply getting the Fedora version of the code to *compile* - it doesn't actually do anything useful. In case (1), all the APIs (including those to define/undefine/start/destroy interfaces) are present, but create/delete/start/destroy fail; only list and dumpxml work. In case (2) all of the APIs are still there but they *all* fail. This leads to even more confusion and frustration. > The UI for starting/stopping interfaces may have had more usage but > I'm fine telling people to go to the command line if they need to > change host interface state. These types of things are not virt > specific in any way and have little to specifically do with virt, > besides bridges. > > Also as a side point, I don't think any major libvirt users are > actually using the libvirt interface APIs aside from maybe listing > existing interfaces. I thought vdsm/rhev/ovirt had some interface > usage at one point but I looked recently and don't see any... Right. The original intent as I understand it (I came in partway through the initial discussion/design, wrote the libvirt APIs hooking up to netcf, and took over maintainership of netcf after the original author moved on), was that someone thought that a management system like ovirt needed the ability to provision a virtualization compute node completely from a single API, and one of the things they needed was the ability to attach the physical ethernet to a bridge, *and* they wanted libvirt provide that one API. In the end though, they wanted other things not available from libvirt's interface API (and which went beyond the scope of libvirt's API, so they did their own thing and ended up not using libvirt for that task anyway. Since then it has been more of a curiousity, and a source of bug reports, than anything else (well, there was awhile when the "virsh iface-bridge eth0 br0" command worked very nicely, but behavior changed with each new release of NetworkManager) > > virt-manager will still use interface APIs behind the scenes, to get > lists of host interfaces for enumerating bridges for example, but > that's really all I see for virt-manager going forward > > Comments? Where to begin? Oh, I guess I already have :-) (The following is my opinion; others may disagree, and I'm always open to hearing a less cynical view than my own :-)) We didn't realize it back in 2008-2009, but netcf (the backend of libvirt's interface API) was doomed from the start (again, in my opinion) for several reasons: 1) In order to really catch on, netcf (and thus libvirt's virInterface APIs) would need to work well on at least *most* distros (and for all supported versions of any supported distro), and the behavior would need to remain consistent from version to version. But (unlike most other functionality in libvirt, where at least the code is identical for different Linux distros, with maybe a few small differences here and there) there are too many different models of host network configuration (different distros, different releases of those distros, multiple solutions on a single distro) that would need to be catered to in order to make the concept of a single unified network configuration API work on all those distros/versions/network config subsystems, and since since each camp already has a working API available, it's difficult to convince anyone of the usefulness of putting in a bunch of work just to create a different API that does the same thing (from their POV) as the existing API A few anecdotes about "support" for various distros: danpb went to the effort to create a debian port of netcf to hopefully jumpstart support on other distros, but it never really got much love from debian/ubuntu people; there was a Suse port written and abandoned by someone whose company used Suse in some embedded product (he stopped working on it due to employer restrictions iirc), but afaik the suse folks themselves had their own ideas about network configuration and weren't interested in enhancing/maintaining anything in netcf; then someone from gentoo (iirc) made a backend for the libvirt interface API that used udev to report the currently active interfaces on the host (*not* their configuration) and it didn't/doesn't support any of the APIs to manage configuration or lifecycle of the interfaces - this was both a blessing and a curse. And as for ArchLinux - someone modified the netcf source just enough to make it *build* on Arch, and added it to their package repo (or whatever it is they have), but it made no effort to actually read/write Arch's config files, so it was in all respects a curse. 2) In many cases there is more than one way to represent one particular config on a host (making netcf's operations on the config non-idempotent at the least, and unable to cope with strange methods of configuring at worst (e.g. on debian/ubuntu the network config can be in multiple files, and I think it can include raw shell commands, but netcf will always write it to a single file), The fact that the method used for reading/writing config files (augeas) ignores/discards anything unrecognized (unsupported options, comments) certainly doesn't help anything. 3) The rest of the network eco-system is constantly changing in subtle ways that make it nearly impossible to continue operating properly without constant tweaks. One example - on systems that use ifcfg files (Fedora/RHEL/CentOS), in the past it was necessary to separately ifup a bridge device and the ethernet that was attached to it (and during certain periods/conditions it was necessary to ifup the bridge first and then the ethernet, and at other times/conditions the order had to be the opposite. But recently I've noticed that an ifup of the bridge will take care of both. Oh, but this changes if NM is disabled (or it did a year or two ago - Seriously I gave up trying to keep track awhile back.) 4) internally - augeas is cool (the library used to read/write the config files) and all, but it's a bit strange and, I don't know about anyone else, but netcf is the *only* place I ever use xslt (netcf uses it to translate an augeas config tree to/from xml). Unfortunately, unfamiliarity and busy schedules combine to produce neglect. I know this is more of an answer than you were looking for, but to shorten it - I personally have no problem with you removing the libvirt Interface API UI from virt-manager, and I see this as another symptom that the virInterface API is mostly unnecessary, unused, and maybe should be included in current discussions about deprecating features in libvirt (perhaps with the exception of the ListAllInterfaces API). _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
