This update fixes a race condition that exists during automatic startup of prestarted virtual machines in virtual machine pools and manual operations of virtual machines in the pool. The condition caused virtual machines to lose its disks while being returned to the virtual machine pool.
Description of problem:
When a pool VM is returned to the pull it sometimes loses its disk and cannot be prestarted any more as it does not have any disk.
Version-Release number of selected component (if applicable):
rhevm-3.6.5.3-0.1.el6.noarch
How reproducible:
Time to time as this is a race condition.
Steps to Reproduce:
1. Return a pool VM to the pool exactly in the same time when the VMs are automatically being prestarted. (every VmPoolMonitorIntervalInMinutes)
Actual results:
Vm loses all disk volumes and is not bale to start any more.
Expected results:
Vm does not lose the volumes (DestroyImageVDSCommand is not triggered twice)
Ran whole vm pools test plan on automation several times, In addition wrote another automated test with a vm pool with all vms set as prestarted, and user allocating vms, then detaching, also allocating and stopping the vms, and a bit of both, all that for around 1 hour.. Did not produce the bug.
Bug didn't re produce at no point.
Verified running with rhevm-4.0.2.3-0.1.el7ev.noarch, all tests passed.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHEA-2016-1743.html
Description of problem: When a pool VM is returned to the pull it sometimes loses its disk and cannot be prestarted any more as it does not have any disk. Version-Release number of selected component (if applicable): rhevm-3.6.5.3-0.1.el6.noarch How reproducible: Time to time as this is a race condition. Steps to Reproduce: 1. Return a pool VM to the pool exactly in the same time when the VMs are automatically being prestarted. (every VmPoolMonitorIntervalInMinutes) Actual results: Vm loses all disk volumes and is not bale to start any more. Expected results: Vm does not lose the volumes (DestroyImageVDSCommand is not triggered twice)