Bug 874443 - VM is in down status while its images are in locked status (breaks backward compatibility)
VM is in down status while its images are in locked status (breaks backward c...
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine (Show other bugs)
3.1.0
x86_64 Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Omer Frenkel
Jakub Libosvar
virt
: Improvement, Regression
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-11-08 03:25 EST by Jakub Libosvar
Modified: 2015-09-22 09 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Release Note
Doc Text:
In previous releases when the disk image of a virtual machine was being modified or used by a task the entire virtual machine was locked. This lock is now more specific and applies to the disk. This means that users are still able to perform additional tasks on the virtual machine, such as adding or removing disks, concurrently. As a result of this change of behavior the virtual machine status may indicate that a virtual machine is "Up" when the attached disk is in fact being used by another task. Users will not be aware of this lock until such time as they attempt to perform an action that requires a lock on the disk.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-25 09:31:13 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
backend log (10.33 KB, text/x-log)
2012-11-08 03:25 EST, Jakub Libosvar
no flags Details

  None (edit)
Description Jakub Libosvar 2012-11-08 03:25:45 EST
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:
Comment 1 Yaniv Kaul 2012-11-08 04:02:00 EST
That breaks existing 3.0 scripts running against 3.1.
Setting as Regression and Urgent severity.
We got reports about it.
Comment 2 Omer Frenkel 2012-11-08 04:34:46 EST
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.
Comment 3 Yaniv Kaul 2012-11-08 04:55:10 EST
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).
Comment 4 Yaniv Kaul 2012-11-08 04:55:50 EST
(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)
Comment 5 Barak 2012-11-08 05:10:26 EST
(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.
Comment 13 Ohad Levy 2013-02-19 16:23:03 EST
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.
Comment 14 Michal Skrivanek 2013-06-25 09:31:13 EDT
foreman is fixed now and hopefully other people are now used to this behavior as well....

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