Bug 1308697

Summary: VMs stuck in "Waiting for Launch" state until engine restarted, yet VMs were actually running on the host.
Product: Red Hat Enterprise Virtualization Manager Reporter: Gordon Watson <gwatson>
Component: ovirt-engineAssignee: Vinzenz Feenstra [evilissimo] <vfeenstr>
Status: CLOSED WORKSFORME QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 3.5.7CC: fromani, gklein, gwatson, lsurette, michal.skrivanek, nsoffer, pkliczew, rbalakri, Rhev-m-bugs, tjelinek, vfeenstr, yeylon, ykaul
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-25 07:48:22 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Gordon Watson 2016-02-15 19:17:53 UTC 
Description of problem:

After some VMs were restarted on a specific host, they got stuck in a 'Waiting for Launch' state, but only as seen by the engine. On the host, they were all 'Up' and the guests were accessible and working as expected.

As a test, one of these VMs was started on a different host and it came up ok. When it was then started on the same host as the ones that were "stuck", it too became stuck in 'Waiting for Launch'.

This sounded like a host-related issue at first, but since the easiest thing to try was to restart ovirt-engine, that was performed and that resolved the problem. Nothing was done of that host at all to affect this.


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

RHEV 3.5.7
RHEV-H 7.2 (20160105.1.el7) hosts 


How reproducible:

Not.


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:
Comment 12 Vinzenz Feenstra [evilissimo] 2016-02-24 08:27:49 UTC 
Ok after all our investigations did go no where, I need to ask some more questions:

@Gordon:
- Are/Were there any 'Stateless' VMs running on the affected host?
- Is that issue still reproducible to the customer? If so, could you please try to give some more information on what you do when this happens?