On Fri, Oct 05, 2018 at 11:13:15AM -0400, Laine Stump wrote: > 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). That was verbose answer :) anyway, nice summary of what was happening. I can only agree with Laine that we can safely remove this UI from virt-manager. Pavel
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
