Bug 850854 - Performing hotplug to VM with the Network that is not attached to the host fails with incorrect error
Performing hotplug to VM with the Network that is not attached to the host fa...
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Muli Salem
GenadiC
network
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-22 10:34 EDT by GenadiC
Modified: 2016-02-10 14:50 EST (History)
8 users (show)

See Also:
Fixed In Version: SI18
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-12-04 14:58:55 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Network
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
engine log (297.55 KB, application/octet-stream)
2012-08-22 10:34 EDT, GenadiC
no flags Details

  None (edit)
Description GenadiC 2012-08-22 10:34:42 EDT
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 03:59:43 EDT
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 11:47:49 EDT
(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 01:44:17 EDT
> 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 08:31:34 EDT
> 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 07:38:11 EDT
Please ignore Comment 4.
Comment 6 Muli Salem 2012-08-30 12:13:00 EDT
Proposed patch in:

http://gerrit.ovirt.org/#/c/7550/
Comment 8 GenadiC 2012-09-06 07:52:32 EDT
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 14:46:00 EDT
Proposed patch in: 

http://gerrit.ovirt.org/#/c/7835/
Comment 11 GenadiC 2012-09-16 04:12:50 EDT
Verified in SI18

Note You need to log in before you can comment on or make changes to this bug.