Hide Forgot
Description of problem: There's no use for two statuses for VM migration - to and from. See https://github.com/oVirt/ovirt-engine/blob/2a00dda492e72e0c24e91c5a1880af4825612ec6/backend/manager/modules/common/src/main/java/org/ovirt/engine/core/common/businessentities/VMStatus.java#L11 and other places. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I wouldn't be so sure it's unused, though Arik is now in refactoring this code, so maybe have some thoughts
Currently it is used. We differentiate the following transitions: MigratingFrom -> Up => migration failed MigratingTo -> Up => migration succeeded. It might look like a duplication since at the beginning we store both source host at run_on_vds and destination host at migrating_to_vds - so in this state we can have just one 'migrating' status and determine according to the host the VM is running on whether we're actually in MigratingFrom or MigratingTo. But after the hand-off run_on_vds points to the destination host (when we detect that the VM is down on source before being up on the destination) and then, if we'll have only one status we will need to either check if run_on_vds equals to migrating_to_vds or to store somehow that hand-over was done in order to know we're know in the MigratingTo state. And when dealing with migrations that were not initiated from the engine, we don't have the migrating_to_vds field (that's the case for hosted-engine VMs sometimes)..
Need to separate with what is in the engine, and what the user is using. The user just wants to see what VMs are in migration state. For this, it should be just 'state = Migrating' and not ' state = MigratingFrom or state = MigratingTo' search. However, I'm wondering if that makes sense in the postcopy age. I can imagine a VM with regular migration staying in 'MigratingFrom' and with postcopy, more time on 'MigratingTo' (or vice-versa...).
(In reply to Yaniv Kaul from comment #3) > Need to separate with what is in the engine, and what the user is using. The > user just wants to see what VMs are in migration state. For this, it should > be just 'state = Migrating' and not ' state = MigratingFrom or state = > MigratingTo' search. just a note that in UI we present in the VM status column only one status: Migrating (one icon, one tooltip) so it really is only about the search box > > However, I'm wondering if that makes sense in the postcopy age. I can > imagine a VM with regular migration staying in 'MigratingFrom' and with > postcopy, more time on 'MigratingTo' (or vice-versa...). Post copy age will not influence us that much. Even if we will enable it than only for a very short time at the end of migration for VMs which just keep stalling for long time.
re search - the MigratingTo state is almost entirely internal. We do not show these VMs, their updates from host are being ignored most of the time. So, yeah, it would make sense to have a single state...but the field is generic and has a tight connection to internal representation, and IMHO it would be more confusing to come up with an exception just for migration