Description of problem: It should remove ";vdsmdummy;" in cockpit after register to RHEVM. Version-Release number of selected component (if applicable): rhev-hypervisor7-ng-4.0-20160608.0.x86_64 cockpit-ovirt-dashboard-0.10.3-0.0.1.el7ev.noarch imgbased-0.7.0-0.1.el7ev.noarch redhat-release-rhev-hypervisor-4.0-0.6.el7.x86_64 vdsm-4.18.2-0.el7ev.x86_64 How reproducible: 100% Steps to Reproduce: 1. install rhev-hypervisor7-ng-4.0-20160608.0.x86_64 2. Register to RHEVM 3. Check the network page in cockpit Actual results: It shows ";vdsmdummy;" as a interface. Expected results: It should remove ";vdsmdummy;" as a interface. Additional info:
Dan, can vdsm learn to not create this bridge?
Vdsm needs this VM for implementing non-wired vNICs. Theoretically, we can create it much later (e.g. before starting a VM), but it won't be fun. What's the big problem in reporting oVirt bridges as Cockpit interfaces?
(In reply to Dan Kenigsberg from comment #2) > Vdsm needs this VM for implementing non-wired vNICs. Theoretically, we can > create it much later (e.g. before starting a VM), but it won't be fun. > > What's the big problem in reporting oVirt bridges as Cockpit interfaces? If you report this as cockpit interface, it means it can be managed or modified which should not. So it should be better not to report this bridge at all.
QE suggest to include this fix in RHV 4.0 GA.
Cockpit is showing all network devices. if it should not be shown, then it must not be created. Thus moving to vdsm which can consider to remove this device.
We cannot just remove it, it's required for disconnected vNICs. Fabian, do you think that cockpit could add a blacklist of devices not to show in its UI?
Hm, there is actually no cockpit specific configuration, so it would be an NM blacklist. But to me that does not look like the right direction. IMO if the bridge is needed, then we should expose it.