Bug 1003943 - Running vm in "runOnce" mode prevent to unlink vnic from vm
Running vm in "runOnce" mode prevent to unlink vnic from vm
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
3.3.0
Unspecified Unspecified
high Severity high
: ---
: 3.2.4
Assigned To: psebek
Pavel Stehlik
network
: ZStream
Depends On: 1001001
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-03 10:38 EDT by Idith Tal-Kohen
Modified: 2016-02-10 14:51 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1001001
Environment:
Last Closed: 2013-09-03 11:55:23 EDT
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)


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 18796 None None None Never

  None (edit)
Description Idith Tal-Kohen 2013-09-03 10:38:43 EDT
+++ This bug was initially created as a clone of Bug #1001001 +++

Description of problem:
Running vm in "runOnce" mode prevent to unlink  vnic from vm with error message:
"Error while executing action Edit VM Interface properties: Unexpected exception"

Version-Release number of selected component (if applicable):
is11
host-vdsm-4.12.0-61.git8178ec2.el6ev, libvirt-0.10.2-18.el6_4.9

How reproducible:
Always

Steps to Reproduce:
1. instal vm on host with network and disk
2. start vm in runOnce mode
3. Try to change link state of one of vnics to down

Actual results:
error message:
"Error while executing action Edit VM Interface properties: Unexpected exception"

Expected results:
vnic change link state to down

Additional info:
In run mode all works fine, also the same thing is relevant for sf20
boot order hd, cdrom, pixe

--- Additional comment from Dan Kenigsberg on 2013-08-27 16:31:08 EDT ---

domxml is created with

                <interface type="bridge">
                        <mac address="00:1a:4a:23:a1:a9"/>
                        <model type="virtio"/>
                        <source bridge="rhevm"/>
                        <filterref filter="vdsm-no-mac-spoofing"/>
                        <link state="up"/>
                        <boot order="2"/>
                </interface>

but calling updateDevice with

<interface type="bridge">
        <address bus="0x00" domain="0x0000" function="0x0" slot="0x03" type="pci"/>
        <mac address="00:1a:4a:23:a1:a9"/>
        <model type="virtio"/>
        <source bridge="rhevm"/>
        <filterref filter="vdsm-no-mac-spoofing"/>
        <link state="down"/>
        <boot order="2"/>
</interface>

fails with

libvirtError: this function is not supported by the connection driver: cannot modify network device boot index setting

I am guessing that vdsm should simply not pass the <boot order="2"/> element on updateDevice. The interesting question is: when was this introduced?

--- Additional comment from Dan Kenigsberg on 2013-08-27 16:51:30 EDT ---



--- Additional comment from Dan Kenigsberg on 2013-09-02 08:11:42 EDT ---

libvirt bug 895294 should have fixed this issue in libvirt-0.10.2-19.el6. Vdsm for el6 should only require this libvirt version.

Artyom, would you verify that with the proper libvirt, the issue disappears?

--- Additional comment from Dan Kenigsberg on 2013-09-02 17:44:27 EDT ---

Until a libvirt-side fix is ready, we may want to hack it on vdsm side with the like of the yet-untested http://gerrit.ovirt.org/18796 .
Comment 1 Dan Kenigsberg 2013-09-03 11:55:23 EDT
This bug was cloned due to a misunderstanding. It stems from a libvirt bug, and should be fixed there - not in vdsm, certainly not in its z-stream.

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