Description of problem: engine might get event on a status, which is not relevant anymore, because the status was already changed by the engine. scenario for example: vm is powering-up, user select to migrate the vm, the moment the engine change the status to 'migrating-from' event received with 'up' on the source host. this will cause the engine to think the migration failed. Version-Release number of selected component (if applicable): 3.6 How reproducible: hard to reproduce
the problem is the engine cannot differ between the 'up' event received by chance because the vm moved from powering-up to up the moment the migration requested or because migration failed. we discussed the following possible solution: use VDSM's time ("motify time") when engine changes VM - when the engine triggers an operation in VDSM that is expected to change VM's status, it gets back the time in VDSM and we will use it as a timestamp Pros: - less changes in the backend - one clock Cons: - changes the API between VDSM and engine
since this is currently only theoretical race, and wasn't reported by anyone using the system, pushing to 4.0
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Moving from 4.0 alpha to 4.0 beta since 4.0 alpha has been already released and bug is not ON_QA.
oVirt 4.0 beta has been released, moving to RC milestone.
since this is still a theoretical race no one have ever faced in reality, pushing to 4.1
The bug was not addressed in time for 4.1. Postponing to 4.2
This bug has been opened in 2015 as a theoretical possibility. It was never actually hit by anyone in this 2 years. Also the consequence is only a failed migration which will pass on next try. Closing due to capacity. Please feel free to reopen if you think this is an important thing.