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): 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
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?
*** Bug 999045 has been marked as a duplicate of this bug. ***
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?
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 .
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?
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?
Hu Jianwe has already verified in bug 1003934 that this bug is solved by the newer 6.4.z libvirt.
Moving back to MODIFIED as libvirt-0.10.2-18.el6_4.14 is out there, and should be pulled by Vdsm.
works on is16 with RHEL 6.5 and libvirt-0.10.2-24.el6.x86_64
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: https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes Thanks in advance.
No need for doc since we only started using libvirt's updateDevice in rhev-3.3, hence this issue was not noticeable by customers.
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. http://rhn.redhat.com/errata/RHBA-2014-0040.html