Created attachment 1303599 [details] engine and vdsm logs Description of problem: When restarting VDSM while VM is running and after that powering off the VM, virsh report that VM state is running, by looking on the UI the VM is down. Id Name State ---------------------------------------------------- 71 golden_env_mixed_virtio_0 running Version-Release number of selected component (if applicable): ovirt-engine-4.1.4.2-0.1.el7.noarch vdsm-4.19.23-1.el7ev.x86_64 How reproducible: 100 Steps to Reproduce: 1. Run VM 2. Restart vdsm 3. Power off VM Actual results: Virsh report that VM state still running Expected results: VM should be down Additional info:
Created attachment 1303625 [details] qemu log
would appreciate vdsm logs with debug level
Created attachment 1303690 [details] vdsm log with DEBUG mode
(In reply to Michal Skrivanek from comment #2) > would appreciate vdsm logs with debug level done
Reproduce on RHEL 7.3 as well
Thanks. so far it points to a vdsm recovery problem, not really a recent regression
*** Bug 1474409 has been marked as a duplicate of this bug. ***
yay, it is a recent regression Francesco, please revert Ia4277334c36920bdc275343e3520d2f39851695f I2af090425961361a111360eb66a56899684f2eae
the regression was introduced in 4.19.21
(In reply to Michal Skrivanek from comment #8) > yay, it is a recent regression > Francesco, please revert > Ia4277334c36920bdc275343e3520d2f39851695f > I2af090425961361a111360eb66a56899684f2eae Rationale for the revert: 1. Ia4277334c36920bdc275343e3520d2f39851695f This is actually where we break: https://gerrit.ovirt.org/#/c/78938/3/vdsm/virt/vmdevices/storage.py if not hasattr(self, '_diskType'): if (self.device in ("cdrom", "floppy") or not utils.isBlockDevice(self.path)): self.diskType = DISK_TYPE.FILE else: self.diskType = DISK_TYPE.BLOCK "self.path" may not yet be available at this time in recovery. And the logs provided here indeed demonstrate that it is not available. 2. I2af090425961361a111360eb66a56899684f2eae just depends on the other one, no other reason. This means we need to check master for the same bug.
Denis, please check https://bugzilla.redhat.com/show_bug.cgi?id=1474320#c10
for *this* bug, we will go on with the revert, to quickly unblock 4.1.4. The broader issue deserves more work, currently ongoing on master branch.
Verified on - vdsm-4.19.24-1.el7ev.x86_64
HI Francesco, Can i ask why patches were added to this bug after it was moved to ON_QA and verified? Should this be retested on next build?
I added the real fix to this issue to master, we can remove the extra patches from this bug and clone or open a new bug for the master fix.
(In reply to Nir Soffer from comment #15) > I added the real fix to this issue to master, we can remove the extra patches > from this bug and clone or open a new bug for the master fix. I believe this is exactly what we should do. This report was verified on 4.1.4 and no patches should be added here any more. Please create a proper bug for master in order to test this real fix on master 4.2 as well. Thanks
(In reply to Michael Burman from comment #16) > (In reply to Nir Soffer from comment #15) > > I added the real fix to this issue to master, we can remove the extra patches > > from this bug and clone or open a new bug for the master fix. > > I believe this is exactly what we should do. This report was verified on > 4.1.4 and no patches should be added here any more. > Please create a proper bug for master in order to test this real fix on > master 4.2 as well. Thanks +1 This is verified for 4.1.4 after the revert, are should be retested for 4.1.5
(In reply to Michael Burman from comment #14) > HI Francesco, > > Can i ask why patches were added to this bug after it was moved to ON_QA and > verified? > Should this be retested on next build? Answered in https://bugzilla.redhat.com/show_bug.cgi?id=1474320#c15 - clearing NEEDINFO.
the patches are part of libgfapi. There's no point in adding patches to _this_ bug as this bug is only about a regression in other, unrelated flow