Bug 1001001 - Running vm in "runOnce" mode prevent to unlink vnic from vm
Summary: Running vm in "runOnce" mode prevent to unlink vnic from vm
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.3.0
Assignee: Dan Kenigsberg
QA Contact: Martin Pavlik
Whiteboard: network
Keywords: ZStream
: 999045 (view as bug list)
Depends On: 1003934
Blocks: 1003943
TreeView+ depends on / blocked
Reported: 2013-08-26 09:44 UTC by Artyom
Modified: 2016-02-10 19:48 UTC (History)
13 users (show)

Clone Of:
: 1003943 (view as bug list)
Last Closed: 2014-01-21 16:13:52 UTC

Attachments (Terms of Use)
vdsm engine and virsh dumpxml for run and runOnce modes (50.00 KB, application/gzip)
2013-08-26 09:44 UTC, Artyom
no flags Details

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:0040 normal SHIPPED_LIVE vdsm bug fix and enhancement update 2014-01-21 20:26:21 UTC
oVirt gerrit 18937 None None None Never
oVirt gerrit 18950 None None None Never

Description Artyom 2013-08-26 09:44:39 UTC
Created attachment 790374 [details]
vdsm engine and virsh dumpxml for run and runOnce modes

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):
host-vdsm-4.12.0-61.git8178ec2.el6ev, libvirt-0.10.2-18.el6_4.9

How reproducible:

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

Comment 1 Dan Kenigsberg 2013-08-27 20:31:08 UTC
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"/>

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"/>

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?

Comment 2 Dan Kenigsberg 2013-08-27 20:51:30 UTC
*** Bug 999045 has been marked as a duplicate of this bug. ***

Comment 3 Dan Kenigsberg 2013-09-02 12:11:42 UTC
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?

Comment 4 Dan Kenigsberg 2013-09-02 21:44:27 UTC
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 6 Artyom 2013-09-03 15:51:02 UTC
Tried to run vm on host with rhel6.5 and libvirt-0.10.2-23.el6 but running was failed with error message:
"VM vm_run_once is down. Exit message: internal error process exited while connecting to monitor: qemu-kvm: -drive file=/rhev/data-center/b446f5fd-b9cc-4b08-93d3-5ad5b40ba2fc/3370f42f-96e5-4c3b-85ed-bda90fc902f3/images/5c1c0cff-e11b-4d5c-9b8e-b8071b2f82d1/df624dd3-ea11-463a-9db3-98d1be8946c8,if=none,id=drive-virtio-disk0,format=raw,serial=5c1c0cff-e11b-4d5c-9b8e-b8071b2f82d1,cache=none,werror=stop,rerror=stop,aio=threads: could not open disk image /rhev/data-center/b446f5fd-b9cc-4b08-93d3-5ad5b40ba2fc/3370f42f-96e5-4c3b-85ed-bda90fc902f3/images/5c1c0cff-e11b-4d5c-9b8e-b8071b2f82d1/df624dd3-ea11-463a-9db3-98d1be8946c8: Permission denied
Any advice?

Comment 7 Dan Kenigsberg 2013-09-03 16:35:43 UTC
No real idea, but it is certainly unrelated to subject of this bug. Can you start other VMs with this version of libvirt? Other operating systems? with other storage types? Please discuss the issue elsewhere, and drop the needinfo when you have an answer to the question: does the bug reproduce with libvirt >= 0.10.2-19.el6?

Comment 8 Dan Kenigsberg 2013-09-07 16:37:27 UTC
Hu Jianwe has already verified in bug 1003934 that this bug is solved by the newer 6.4.z libvirt.

Comment 10 Dan Kenigsberg 2013-09-22 00:07:32 UTC
Moving back to MODIFIED as libvirt-0.10.2-18.el6_4.14 is out there, and should be pulled by Vdsm.

Comment 11 Martin Pavlik 2013-09-24 14:07:46 UTC
works on is16 with RHEL 6.5 and libvirt-0.10.2-24.el6.x86_64

Comment 12 Charlie 2013-11-28 00:28:05 UTC
This bug is currently attached to errata RHBA-2013:15291. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to 
minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:


Thanks in advance.

Comment 13 Dan Kenigsberg 2013-12-02 17:28:10 UTC
No need for doc since we only started using libvirt's updateDevice in rhev-3.3, hence this issue was not noticeable by customers.

Comment 14 errata-xmlrpc 2014-01-21 16:13:52 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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