Bug 1537534
Summary: | UpdateVmCommand fails with NullPointerException after failed Hot-plug of a VM lease due to VM power off | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [oVirt] ovirt-engine | Reporter: | Elad <ebenahar> | ||||||
Component: | BLL.Storage | Assignee: | Eyal Shenitzky <eshenitz> | ||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Natalie Gavrielov <ngavrilo> | ||||||
Severity: | high | Docs Contact: | |||||||
Priority: | high | ||||||||
Version: | 4.2.1 | CC: | ahadas, amureini, bugs, ebenahar, lveyde, tnisan, ylavi | ||||||
Target Milestone: | ovirt-4.2.2 | Flags: | rule-engine:
ovirt-4.2+
ylavi: blocker+ |
||||||
Target Release: | 4.2.2.2 | ||||||||
Hardware: | x86_64 | ||||||||
OS: | Unspecified | ||||||||
Whiteboard: | |||||||||
Fixed In Version: | ovirt-engine-4.2.2 | Doc Type: | If docs needed, set a value | ||||||
Doc Text: | Story Points: | --- | |||||||
Clone Of: | Environment: | ||||||||
Last Closed: | 2018-03-29 11:00:12 UTC | Type: | Bug | ||||||
Regression: | --- | Mount Type: | --- | ||||||
Documentation: | --- | CRM: | |||||||
Verified Versions: | Category: | --- | |||||||
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||
Embargoed: | |||||||||
Attachments: |
|
Description
Elad
2018-01-23 13:15:30 UTC
Sorry, the fix of bug 1522832 was to rhevm-4.1.9, there doesn't seem to be actual relation between the bug and the fix of bug 1522832, except for the steps to reproduce. Version-Release number of selected component (if applicable): rhvm-4.2.1.2-0.1.el7.noarch vdsm-4.20.14-1.el7ev.x86_64 Why is this high severity? What are the odds and why would you add a lease and immediately power it off? The severity is high because once the bug occurs, there is no way to update the VM anymore Elad, Something seems unclear to me. After you edit the VM and add a lease, when you try to edit the VM for the second time (if I understand correctly - before the first edit for add a lease was done) and pressed 'OK' you should receive an error - 'operation canceled' because there is a lock on the VM until the lease will be added (even if you shut down the VM). I failed to reproduce this issue, I tried to edit the VM once again right after the VM shutdown - received 'operation canceled' error When I try to edit the VM after the lease was added but the hot-plug failed - all works fine. I attached a screenshot with the dialog box that should pop when you try to edit the VM while the previous VM edit wasn't done yet. Created attachment 1385345 [details]
operation canceled screenshot
(In reply to Eyal Shenitzky from comment #4) Eyal, just wait for the lease creation task to finish and then try to update the VM. Steps to reproduce correction: In step #1, The VM has to be created with default HA configuration (non HA with AUTO_RESUME as resume behavior) Ok, So after the fix in the steps to reproduce, it seems that when we edit the VM and added a lease, the resume behavior change by default to 'KILL'. The change in the resume behavior cannot take place only after a reboot of the VM. When the VM shutdown while it was in the middle of the update and there is a lock on it, ProcessDownVmCommand try to initiate UpdateVmCommand to apply Next Run Config of the VM, but it failed to acquire a lock on the VM. 2018-01-24 12:28:35,500+02 WARN [org.ovirt.engine.core.bll.ProcessDownVmCommand] (EE-ManagedThreadFactory-engine-Thread-2321) [3afc43b1] Could not acquire lock for UpdateVmCommand to apply Next Run Config of VM '1747e6fb-270e-4882-8175-031805dda4c0' So in the next time we try to update the VM an exception is thrown when trying to run SetDestroyOnReboot (vm.getRunOnVds() = null). Arik, can you please take a look? Verified using: rhvm-4.2.2.1-0.1.el7.noarch vdsm-4.20.19-1.el7ev.x86_64 Tested scenario described in comment 0 with the correction in comment 7. Result: UI: Operation Canceled Error while executing action: test-vm: Cannot edit VM. VM is being updated. engine.log: No NPE found. This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report. |