Thanks Cyphermox for co-testign this with me. Here an example of his better interface overview now:
virsh # iface-list Name State MAC Address --------------------------------------------------- enp3s0 active c8:60:00:6d:8c:07 lxdbr0 active fe:34:73:b4:77:ab maas active c8:60:00:6d:8c:07 staging active c8:60:00:6d:8c:07 Vlans are not always listed, but that still is much better than before. FYI: there is a test build in https://launchpad.net/~ci-train-ppa- service/+archive/ubuntu/3251 I did my own tests on this as well, on an upgrade from xenial all that most have in their E/N/I is just "lo" so that is what they see (but nobody wants/needs lo - it is just there because it is listed in E/N/I). $ virsh iface-list Name State MAC Address --------------------------------------------------- lo active 00:00:00:00:00:00 After the update to the proposed version I got much better output. $ virsh iface-list Name State MAC Address --------------------------------------------------- enp0s25 active 54:ee:75:61:c1:97 lxdbr0 active fe:24:e7:8e:21:8d wlp4s0 active 94:65:9c:0e:35:12 Btw those are just the active interfaces, you can list passive/inactive ones still (e.g. virt manager shows these greyed out). $ virsh iface-list --all Name State MAC Address --------------------------------------------------- conjureup0 inactive 12:ab:dc:f1:41:bd enp0s25 active 54:ee:75:61:c1:97 lo inactive 00:00:00:00:00:00 lxdbr0 active fe:24:e7:8e:21:8d strswanbr1 inactive 52:54:00:fc:52:4d strswanbr2 inactive 52:54:00:14:9e:81 virbr0 inactive 52:54:00:f4:ea:12 wlp4s0 active 94:65:9c:0e:35:12 I even see slaves devices on bridges in virt-manager now. Further functions of the iface- API space are good as well, like name<->mac translation. $ virsh iface-name 54:ee:75:61:c1:97 enp0s25 $ virsh iface-mac enp0s25 54:ee:75:61:c1:97 Even XML generation works if you want to use the snippet for other defines (e.g. guest forwards). $ virsh iface-dumpxml enp0s25 <interface type='ethernet' name='enp0s25'> <mtu size='1500'/> <link speed='1000' state='up'/> <mac address='54:ee:75:61:c1:97'/> </interface> Only the define/destroy/edit actions are now (intentionally) blocked. The console calls are ok in the refusal message, just like in virt-manager. $ virsh iface-edit enp0s25 error: this function is not supported by the connection driver: virInterfaceDefineXML Failed. Try again? [y,n,f,?]: >From a "virt-manager" and similar tools perspective making changes now looks >reasonably guarded. If you try to do so you get "Error setting ... this function is not supported by the connection driver: virtInterdaceDefineXML" I also wanted to check a few more corner cases, so I did: - s390x system (for having odd device types) with some defined in E/N/I (was a Xenial upgrade) - a lxd container for udev/containers can be odd - Thanks to cycphermox for his MAAS based tests as well The container looks good, from an empty device view it got to # virsh iface-list --all Name State MAC Address --------------------------------------------------- eth0 active 00:16:3e:35:78:53 lo inactive 00:00:00:00:00:00 virbr0 inactive 52:54:00:ec:18:e5 Which ist just matching my "ip link" output The s390x system had shown the E/N/I devices before upgrade to the fixed version for being found in E/N/I but missed a few others. $ virsh iface-list --all Name State MAC Address --------------------------------------------------- encc000 active 02:00:00:8e:1a:31 encc000.2654 active 02:00:00:8e:1a:31 lo active 00:00:00:00:00:00 With udev mode this is much better catching all the others on my system that were formerly forgotten. $ virsh iface-list --all Name State MAC Address --------------------------------------------------- encc000 active 02:00:00:8e:1a:31 encc000.2654 active 02:00:00:8e:1a:31 encc003 inactive 02:00:00:28:29:a6 lo inactive 00:00:00:00:00:00 lxdbr0 active fe:42:16:55:ae:8b ovs-system inactive 4a:fd:83:ed:05:89 ovsbr0 inactive 52:17:63:0d:4b:ab virbr0 inactive 52:54:00:6e:c3:70 So all that seems good to me to go forward with that approach - and even worst case if we identify issues down the road it seems much better than the current broken state. Furthermore we actually don't want libvirt to try to be another netplan that translates XMLs into different backends. There is a reason why this was broken so long and never anybody complained - this particular subfeature of libvirt is mostly unused. I discussed with several people and the general reply was "what having a remote to libvirt allows them to change host interfaces, I don't want that ...". So lets disable the write support for now and use udev to provide a fixed interface listing. I started a set of generic regression tests on x86/ppc64el/s390x against this before pushing to cosmic. I'll report on test results later, but in general we want to sync on details like: - ack to push this to cosmic - ack and coordinate on an SRU for this to Bionic - Do we want to archive-remove netcf in Cosmic (or give it a ifupdown dependency)? - netcf in Bionic remove/dep/..? -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1764314 Title: libvirt doesn't show all interfaces To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/1764314/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
