Description of problem: allocatevm action for pre-started pools results with error and also, such pool can't be removed from the engine with the same error. Version-Release number of selected component (if applicable): ovirt-engine-4.3.3.1-0.1.el7.noarch How reproducible:100% Steps to Reproduce: 1. Create pool with prestarted vm (I created pool with two vms , both prestarted) 2. try to allocate with rest API : POST https://{{host}}/ovirt-engine/api/vmpools/9e605316-cddf-4bd1-9f0e-e8f2f10aed1d/allocatevm body: <action> <async>false</async> <grace_period> <expiry>10</expiry> </grace_period> </action> Actual results: brings error [Can not allocate and run VM from VM-Pool. Related operation is currently in progress. Please try again later.]. Also, such a pool could be never removed from the engine with the same error. Expected results: no error Additional info:
This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
logs?
Created attachment 1555739 [details] engine.log engine.log attached
Created attachment 1555886 [details] engine from last master build re-tested on upstream build ovirt-engine-4.3.3.6-0.0.master.20190416081415.git5975555.el7.noarch (updated today ). bug still happens. new log attached .
This is also harming vm-pools that were made in 4.2. After the upgrade to 4.3 (ovirt-engine-4.3.3.5-0.1.el7.noarch), pre-started vm-pools can't be allocated.
Created attachment 1663505 [details] Screen shot showing that the rest api allocatevm command succeeds. Created a pool with 2 VMs prestarted and as per the screen shot sent the allocatevm rest api message and it succeeded. Reviewed an issue where the the VMs did not seem to prestart, but on further investigation found that the VMs do eventually restart after a few minutes. This may be advisable being that the VMs need some time to move from an Image Locked status while being created to a Down status as an indicator for prestarting the VM. One may consider however reducing the polling time of the pool monitor, but this would be a separate issue.
I read this as "QE, please re-test". Correct?
(In reply to Ryan Barry from comment #7) > I read this as "QE, please re-test". Correct? Correct.
(In reply to Steven Rosenberg from comment #8) > (In reply to Ryan Barry from comment #7) > > I read this as "QE, please re-test". Correct? > > Correct. then either move bug to ON_QA or ask Polina kindly via needinfo Polina, can you please retest as Steven requested?
re-tested on http://bob-dr.lab.eng.brq.redhat.com/builds/4.3/rhv-4.3.9-7 and on http://bob-dr.lab.eng.brq.redhat.com/builds/4.4/rhv-4.4.0-23 works correctly. no error. correct response <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <action> <async>false</async> <grace_period> <expiry>10</expiry> </grace_period> <status>complete</status> <vm href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c" id="5bc73c95-f9e1-4fc1-ab46-e39a3173432c"> <actions> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/detach" rel="detach"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/export" rel="export"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/ticket" rel="ticket"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/previewsnapshot" rel="previewsnapshot"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/reordermacaddresses" rel="reordermacaddresses"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/thawfilesystems" rel="thawfilesystems"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/undosnapshot" rel="undosnapshot"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/commitsnapshot" rel="commitsnapshot"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/reboot" rel="reboot"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/migrate" rel="migrate"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/cancelmigration" rel="cancelmigration"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/clone" rel="clone"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/logon" rel="logon"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/maintenance" rel="maintenance"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/freezefilesystems" rel="freezefilesystems"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/shutdown" rel="shutdown"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/start" rel="start"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/stop" rel="stop"/> <link href="/ovirt-engine/api/vms/5bc73c95-f9e1-4fc1-ab46-e39a3173432c/suspend" rel="suspend"/> </actions> </vm> </action>
(In reply to RHEL Program Management from comment #11) > This bug report has Keywords: Regression or TestBlocker. > Since no regressions or test blockers are allowed between releases, it is > also being identified as a blocker for this release. Please resolve ASAP. Polina verified this in Comment 10. Should be closed.
Not closed, but new milestone
based on comment#10
This bugzilla is included in oVirt 4.3.9 release, published on March 20th 2020. Since the problem described in this bug report should be resolved in oVirt 4.3.9 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.