Created attachment 640643 [details] backend log Description of problem: When disk is created for VM, VM is kept in Down status but cannot be started. Getting error message: Error while executing action: Cannot run VM: The disks vm_Disk3 are locked. Please try again in a few minutes. Version-Release number of selected component (if applicable): rhevm-3.1.0-26.el6ev.noarch How reproducible: Always Steps to Reproduce: 1. Create a disk for VM 2. While disk is in locked status, start VM Actual results: VM cannot be started although it's in down status Expected results: VM should have some status, that says VM is not ready to start Additional info:
That breaks existing 3.0 scripts running against 3.1. Setting as Regression and Urgent severity. We got reports about it.
The return value for the user is the same as before (canDoAction message with explanation why vm can't run): 2012-11-08 09:14:02,830 WARN [org.ovirt.engine.core.bll.RunVmCommand] (ajp-/127.0.0.1:8702-8) CanDoAction of action RunVm failed. Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ACTION_TYPE_FAILED_DISKS_ARE_LOCKED,$diskAliases vm_Disk2 AFAIR, one of the features of 3.1 was not to lock the vm when locking its disks, so operations on other disks can be made, and even run the vm if the disk is inactive.
Please see https://bugzilla.redhat.com/show_bug.cgi?id=872961 (upstream!) which sounds similar, though in this case, the command is sent all the way to VDSM (and not blocked in Engine).
(In reply to comment #2) > The return value for the user is the same as before (canDoAction message > with explanation why vm can't run): > 2012-11-08 09:14:02,830 WARN [org.ovirt.engine.core.bll.RunVmCommand] > (ajp-/127.0.0.1:8702-8) CanDoAction of action RunVm failed. > Reasons:VAR__ACTION__RUN,VAR__TYPE__VM,ACTION_TYPE_FAILED_DISKS_ARE_LOCKED, > $diskAliases vm_Disk2 > > AFAIR, one of the features of 3.1 was not to lock the vm when locking its > disks, so operations on other disks can be made, and even run the vm if the > disk is inactive. All true, but we break 3.0-compatible scripts (example @ https://bugzilla.redhat.com/show_bug.cgi?id=872961#c2)
(In reply to comment #4) . > > All true, but we break 3.0-compatible scripts (example @ > https://bugzilla.redhat.com/show_bug.cgi?id=872961#c2) Per comment #2 on that bz - it looks like the upstream and downstream behavior is different, it looks like that there the command actually got to VDSM.
this effects Foreman (http://theforeman.org) and is tracked upstream at http://projects.theforeman.org/issues/2163. IMHO, this is a BUG and not a feature.
foreman is fixed now and hopefully other people are now used to this behavior as well....