Bug 1468182 - User is able to attempt to start VM before VM lease is created
User is able to attempt to start VM before VM lease is created
Status: NEW
Product: ovirt-engine
Classification: oVirt
Component: BLL.Virt (Show other bugs)
Unspecified Unspecified
unspecified Severity medium (vote)
: ovirt-4.3.0
: ---
Assigned To: Tal Nisan
Depends On:
  Show dependency treegraph
Reported: 2017-07-06 04:41 EDT by Arik
Modified: 2018-03-05 12:16 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.3+

Attachments (Terms of Use)

  None (edit)
Description Arik 2017-07-06 04:41:28 EDT
Description of problem:
When updating a VM to use a VM lease, the update command ends while the async operation of creating the lease is still being executed. Therefore, the lock of the VM that was acquired by UpdateVm may be released before the lease was actually created.
Setting severity to high and not to urgent because if the user tries to start the VM at this stage, it is expected to fail since the lease cannot be acquired. However, this is yet important because we should prevent the user from trying to start the VM in this state with a proper message (conceptually the UpdateVm operation was not ended yet) and more importantly, it prevents us from saving the lease properties in the engine and to send the complete device as part of the engine xml.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Update a VM that was not set with a VM lease to use one.
2. Start the VM

Actual results:
The RunVm command is executed before the end action of AddVmLease is called.

Expected results:
Well, ideally if there is no need to extend the lease volume then the call to add lease should be synchronous and that way we won't badly affect the system's responsiveness. But in case the operation is asynchronous, the UpdateVm command should be ended (and then release the VM's lock) only when that operation is ended, even at the expense of the system's responsiveness.

Additional info:
Comment 1 Arik 2017-09-03 09:07:45 EDT
Added a validation that prevents one from starting the VM during the creation of the lease, so reducing the severity.

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