I wasn't able to re produce the bug on an env with the same version as reported. I understand this is a race condition bug and is very tricky to re produce. Ran whole vm pools test plan on automation, 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. I don't think I'll be able to re produce with my resources, seems as though the user had close to 1000 vms on the pool increasing the probability this would happen at some point. Verified running the same tests on rhevm-3.6.8-0.1.el6.noarch, all tests passed. With no way to re produce and all vm pools tests passing, I think we can verify this bug, please let me know if there are any objections or suggestions how to test the case if you think this is not sufficient.
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/RHBA-2016-1507.html