Description of problem:
If Quotas are enabled, whether in Audit or Enforced mode, and a quota is created, then a virtual disk cannot be edited while the VM is running unless it has already been edited after the quota was created while the VM was down.
It will fail with "Cannot edit Virtual Machine Disk. At least one of the VMs is not down.".
The engine log will show "ACTION_TYPE_FAILED_VM_IS_NOT_DOWN".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create a VM that has one disk and start it.
2. Enable Quotas in that DC.
3. Create a quota.
4. Highlight the VM, select 'Disks' tab and 'Edit'.
5. Modify the 'Extend size by' value or 'Alias' name.
6. Hit 'OK'.
7. "Cannot edit Virtual Machine Disk. At least one of the VMs is not down." will be reported.
Then just to prove the point;
8. Create a second disk.
9. Try to edit this disk. It will be successful.
VM cannot be edited after Quotas have been enabled and a quota created if the VM is up and the disks have not been edited since the quota was created.
The disk should be able to be edited.
moving to 3.5.4 due to capacity planning for 3.5.3.
if you believe this should remain in 3.5.3, please sync with pm/dev/qe and a full triple ack for it. also - ensure priority is set accordingly to the bug status.
Reconstructed the bug in RHEV 3.5
Failed reconstructing the bug in RHEV 3.6
Please advise if we want to solve the bug in RHEV 3.5
(In reply to Dudi Maroshi from comment #4)
> Reconstructed the bug in RHEV 3.5
> Failed reconstructing the bug in RHEV 3.6
> Please advise if we want to solve the bug in RHEV 3.5
How big / invasive / risky is the fix?
Investigated the bug:
1. UpdateVmDiskCommand is testing in the canDoAction method that:
If the disk is connected to a running VM then
If disk is of type IMAGE and the quota changed
fail command. Report ACTION_TYPE_FAILED_VM_IS_NOT_DOWN
2. quota change is tested by comparing recent quota ID (from database) with current ID
If quota enabled on data center. For all existing disks. The recent quota is always null. But the current quota is arbitrary the first in the list box.
Therefore when enabling quota on existing disks. They are no longer editable.
Long term, solving bug 1245931 will solve this correctly.
Short term, assume if recent quota is null, there is no quota change. Will allow block disk update after quota applied.
As for RHEV 3.6 a broken fix for bug 1185826. Fails the test for disk is of type IMAGE or CINDER. Therefore quota change is never tested.
Posted temporary fix for RHEV 3.5
What to do about RHEV 3.6:
1. Fix bug 1185826, masking the problem found in RHEV 3.5
2. Fix problem cause, bug 1245931 in both RHEV versions.
As commented elsewhere, default quota is not a viable option we will have.
pending an u/s and 3.6.0 fix to move this to modify
In reply to comment 5, the tech answer is in comment 6.
Was fixed for ovirt 3.5.z.
Pending decision if we want to address the root cause in master and 3.6.
Currently in ovirt 3.6. The problem is not present due to wrong fix to bug 1185826.
The easiest and fastest is to fix bug 1185826, and apply the fix done for 3.5.z. Very simple fix. The problem cause will remain just bypassed.
The long term solution is to have a defined policy for for dealing with (new vm-disk and existing vm-disk) after (enabling/disabling quota).
Verified on rhevm-backend-3.6.0-0.12.master.el6.noarch
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.