Handle VM state changes during storage live migration #1394
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It is possible that during the storage live migration of a VM the state of that VM changes. This can happen when the VM is started or stopped. When a running VM is stopped, the live migration is cancelled and an offline migration is started instead. The reverse is also true, if a VM is started during and offline migration, the offline migration is cancelled and a live migration is started instead. Since offline migrations use a single rsync server with potentially multiple clients. If we stop a VM but another offline migration is running, that one is allowed to complete before starting a new offline migration. The reverse is also true, if a VM is started while it is part of an offline migration, the offline migration is allowed to complete before starting a live migration. Signed-off-by: Alexander Wels <[email protected]>
dymurray
reviewed
Nov 18, 2024
dymurray
reviewed
Nov 18, 2024
| @@ -376,7 +377,7 @@ func (r *ReconcileMigPlan) getClaims(client compat.Client, plan *migapi.MigPlan) | |||
| } | |||
|
|
|||
| alreadyMigrated := func(pvc core.PersistentVolumeClaim) bool { | |||
| if planuid, exists := pvc.Labels[migapi.MigMigrationLabel]; exists { | |||
| if planuid, exists := pvc.Labels[migapi.MigPlanLabel]; exists { | |||
There was a problem hiding this comment.
Why the switch to the migplan label?
There was a problem hiding this comment.
Because the MigMigrationLabel didn't make sense. Once you migrate, you cannot migrate again, unless you rollback. At which point the migration label is overwritten to the new MigMigration. To me it made much more sense to mark the PVCs with the MigPlan since that will be constant regardless of how many times you migrate and roll back.
dymurray
approved these changes
Nov 18, 2024
pranavgaikwad
approved these changes
Nov 18, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It is possible that during the storage live migration of a VM the state of that VM changes. This can happen when the VM is started or stopped. When a running
VM is stopped, the live migration is cancelled and an offline migration is started instead.
The reverse is also true, if a VM is started during and offline migration, the offline migration is
cancelled and a live migration is started instead.
Since offline migrations use a single rsync server with potentially multiple clients. If we stop a VM but another offline migration is running, that one is allowed to complete before starting a new offline migration. The reverse is also true, if a VM is started while it is part of an offline migration, the offline migration is allowed to complete before starting a live migration.
The following combinations of VM state and changes should behave as described in this table