Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 850854

Summary: Performing hotplug to VM with the Network that is not attached to the host fails with incorrect error
Product: Red Hat Enterprise Virtualization Manager Reporter: GenadiC <gcheresh>
Component: ovirt-engineAssignee: Muli Salem <msalem>
Status: CLOSED CURRENTRELEASE QA Contact: GenadiC <gcheresh>
Severity: high Docs Contact:
Priority: medium    
Version: 3.1.0CC: dyasny, iheim, lpeer, mpavlik, Rhev-m-bugs, sgrinber, yeylon, ykaul
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: network
Fixed In Version: SI18 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-12-04 19:58:55 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
engine log none

Description GenadiC 2012-08-22 14:34:42 UTC
Created attachment 606290 [details]
engine log

Description of problem:
Create Network-A and don't attach it to host.
Run VM on that host and try to hotplug Network-A to that VM
You'll get an error "Cannot get interface MTU"

How reproducible:
Always

Steps to Reproduce:
1.Create Network-A on the Cluster and don't attach it to host
2.Run VM on the host and try to hotplug Network-A to that VM
3.
  
Actual results:
"Cannot get interface MTU" error on engine log
Error while executing action Add NIC to VM: Unexpected exception in GUI

Expected results:
Network should be created as non active
It will be possible to active it only when the network will be added to the host
No error message on MTU should be displayed

Additional info:

2012-08-22 14:46:48,659 ERROR [org.ovirt.engine.core.bll.AddVmInterfaceCommand] (ajp-/127.0.0.1:8009-5) [2185f442] Command org.ovirt.engine.core.bll.AddVmInterfaceCommand throw Vdc Bll exception. With error messag
e VdcBLLException: org.ovirt.engine.core.vdsbroker.vdsbroker.VDSErrorException: VDSGenericException: VDSErrorException: Failed to HotPlugNicVDS, error = Cannot get interface MTU on 'VM_NET': No such device
2012-08-22 14:46:48,662 ERROR [org.ovirt.engine.core.bll.AddVmInterfaceCommand] (ajp-/127.0.0.1:8009-5) [2185f442] Transaction rolled-back for command: org.ovirt.engine.core.bll.AddVmInterfaceCommand.
2012-08-22 14:46:48,662 INFO  [org.ovirt.engine.core.bll.MacPoolManager] (ajp-/127.0.0.1:8009-5) [2185f442] MacPoolManager::freeMac(mac = 00:1a:4a:23:63:5b) - entered

Comment 1 lpeer 2012-08-23 07:59:43 UTC
This behaviour for this flow was not defined before.

Simon what is your take about this? Obviously the current behaviour is wrong.
Does the following behaviour make sense?

In the UI the user can attach any network he would like, either attach it as active or inactive. The backend will block attaching a network in active mode that is not available on the host (the host on which the VM is currently running).

Comment 2 Simon Grinberg 2012-08-26 15:47:49 UTC
(In reply to comment #1)
> This behaviour for this flow was not defined before.
> 
> Simon what is your take about this? Obviously the current behaviour is wrong.
> Does the following behaviour make sense?
> 
> In the UI the user can attach any network he would like, either attach it as
> active or inactive. The backend will block attaching a network in active
> mode that is not available on the host (the host on which the VM is
> currently running).

Meaning (Just to make sure I understand correctly):
1. If the user tries to attach as inactive: success
2. If the user tries to attach as active: Fail and the network not even attached

Error message: "Can't attach and activate. The network does not exist on the hosts the VM is running on."

The above sounds right to me.

What should not happen on case #2, is that the network is attached but as inactive. This may lead to confusion since then the user will see it attached but even if the network has been moved to a different host it will still be inactive until he manually sets it to active.

Comment 3 lpeer 2012-08-27 05:44:17 UTC
> Meaning (Just to make sure I understand correctly):
> 1. If the user tries to attach as inactive: success
> 2. If the user tries to attach as active: Fail and the network not even
> attached
> 
> Error message: "Can't attach and activate. The network does not exist on the
> hosts the VM is running on."
> 
> The above sounds right to me.
> 

good, that would be the implementation.

Comment 4 Muli Salem 2012-08-27 12:31:34 UTC
> Meaning (Just to make sure I understand correctly):
> 1. If the user tries to attach as inactive: success
> 2. If the user tries to attach as active: Fail and the network not even
> attached

The first case can lead to a scenario where the user tries to activate the network later on, although it is not attached to the host - blocking this as well (regardless of whether the VM is UP or DOWN).

Comment 5 Muli Salem 2012-08-28 11:38:11 UTC
Please ignore Comment 4.

Comment 6 Muli Salem 2012-08-30 16:13:00 UTC
Proposed patch in:

http://gerrit.ovirt.org/#/c/7550/

Comment 8 GenadiC 2012-09-06 11:52:32 UTC
The error message is not good enough for the case of activating the network (when it was attached as inactive in the previous step)

Comment 9 Muli Salem 2012-09-06 18:46:00 UTC
Proposed patch in: 

http://gerrit.ovirt.org/#/c/7835/

Comment 11 GenadiC 2012-09-16 08:12:50 UTC
Verified in SI18