+++ 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 .
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.