Description of problem ====================== Given I have a host with a NIC attached to a network When I open the setup-networks dialog via the webadmin UI And drag a NIC which has no attachments over the NIC which has a network attached to it And I press OK to confirm the bond creation And I press 'OK' to confirm the setup networks operation Then a pop-up appears with a message: "Error while executing action HostSetupNetworks: Interface already in use" Version-Release number of selected component (if applicable) ============================================================ ovirt-engine-4.4.0-0.14.master.el7.noarch vdsm-4.40.0-180.giteba0b75.el8ev.x86_64 How reproducible ================ 100% Steps to Reproduce ================== 1. Create a logical network (VM/non-VM). 2. Attach the network to a NIC on a host. 3. Open the setup-networks dialog and drag a NIC which has no networks attached to it over the NIC from step 2 and press 'OK' to confirm the bond creation. 4. Press 'OK' to confirm the setup networks request. Actual results ============== a pop-up appears with a message: "Error while executing action HostSetupNetworks: Interface already in use" Expected results ================ The setup networks succeeds and there is now a bond attached to the network. Additional info =============== There is no importance wheather the network attached is a VM network or not, or what the requested bond mode is. This scenario was tested on RHV 4.3.8 and does not reproduce, hence this is a regression in 4.4
Is this issue reproducing on a host with nmstate enabled?
(In reply to Dominik Holler from comment #2) > Is this issue reproducing on a host with nmstate enabled? Yes. It's not related to nmstate.
Reproduces in build ovirt-engine-4.4.0-0.19.master.el7.noarch
This bug does not only reproduce in UI, but also via REST API. Given I have a host with NIC 'enp1s0f1' attached to network 'moshe' and a NIC 'enp2s0f0' free of attachments, and I would like to transform NIC 'enp1s0f1' to become a slave of a new bond 'bond0' with mode 4 and miimon 100 and also enslave NIC 'enp2s0f0' When I perform a request via REST API as follows: POST {{FQDN}}/ovirt-engine/api/hosts/{host_ID}/setupnetworks <action> <modified_bonds> <host_nic> <name>bond0</name> <bonding> <options> <option> <name>mode</name> <value>4</value> </option> <option> <name>miimon</name> <value>100</value> </option> </options> <slaves> <host_nic> <name>enp1s0f1</name> </host_nic> <host_nic> <name>enp2s0f0</name> </host_nic> </slaves> </bonding> </host_nic> </modified_bonds> </action> Then I receive a reply as follows: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault> <detail>[Cannot setup Networks. Network Interface 'enp1s0f1' cannot become slave, there's network 'moshe' attached to it.]</detail> <reason>Operation Failed</reason> </fault>
Thanks for checking again. (In reply to msheena from comment #4) > Reproduces in build ovirt-engine-4.4.0-0.19.master.el7.noarch Strange, can you please check if the related host uses nmstate? (In reply to msheena from comment #5) > This bug does not only reproduce in UI, but also via REST API. > > Given I have a host with NIC 'enp1s0f1' attached to network 'moshe' and a > NIC 'enp2s0f0' free of attachments, and I would like to transform NIC > 'enp1s0f1' to become a slave of a new bond 'bond0' with mode 4 and miimon > 100 and also enslave NIC 'enp2s0f0' > When I perform a request via REST API as follows: > > POST {{FQDN}}/ovirt-engine/api/hosts/{host_ID}/setupnetworks > > <action> > <modified_bonds> > <host_nic> > <name>bond0</name> > <bonding> > <options> > <option> > <name>mode</name> > <value>4</value> > </option> > <option> > <name>miimon</name> > <value>100</value> > </option> > </options> > <slaves> > <host_nic> > <name>enp1s0f1</name> > </host_nic> > <host_nic> > <name>enp2s0f0</name> > </host_nic> > </slaves> > </bonding> > </host_nic> > </modified_bonds> > </action> > > Then I receive a reply as follows: > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> > <fault> > <detail>[Cannot setup Networks. Network Interface 'enp1s0f1' cannot > become slave, there's network 'moshe' attached to it.]</detail> > <reason>Operation Failed</reason> > </fault> This looks like a different flow, form Engine point of view (maybe the UI does some logic on top). Is the REST behavior the same like in 4.3?
Comment concerning the regression ================================= On 4.3.8.2-0.4.el7 it is possible to bond a NIC attached to a network via WEB UI ONLY!! using REST API a conflict is returned upon trying: <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <fault> <detail>[Cannot setup Networks. Network Interface 'enp1s0f0' cannot become slave, there's network 'vmfex-1' attached to it.]</detail> <reason>Operation Failed</reason> </fault> There seems to be a change in behavior on the UI side from 4.3.8 to 4.4
(In reply to msheena from comment #7) > Comment concerning the regression > ================================= > > On 4.3.8.2-0.4.el7 it is possible to bond a NIC attached to a network via > WEB UI ONLY!! using REST API a conflict is returned upon trying: > > <?xml version="1.0" encoding="UTF-8" standalone="yes"?> > <fault> > <detail>[Cannot setup Networks. Network Interface 'enp1s0f0' cannot > become slave, there's network 'vmfex-1' attached to it.]</detail> > <reason>Operation Failed</reason> > </fault> > > There seems to be a change in behavior on the UI side from 4.3.8 to 4.4 Thanks for checking!
I don't understand where did this come from? [C1_nm_network2] It's not present on the host. If it was taken from the logs it is a leftover of one of our tests, but irrelevant for the bug.
Thanks Moshe and Michael for you patience. Now I see that this is a real bug, which reproduces only for bridged networks.
Can this bug move to QA? It has not referenced patch so I can't decide if QE already has the packages including the fix or not.
Should be fixed in the VDSM version in 4.4.0-26.
Verified on =========== ovirt-engine-4.4.0-0.26.master.el8ev.noarch vdsm-4.40.7-1.el8ev.x86_64 nmstate-0.2.6-4.8.el8.noarch
This bugzilla is included in oVirt 4.4.0 release, published on May 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.4.0 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.