Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Update volume migration doc #840

Open
wants to merge 2 commits into
base: main
Choose a base branch
from
Open

Update volume migration doc #840

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
d691f9f
Add volume migration cancellation and recovery
alicefr Oct 9, 2024
36d0415
Fix the title for volume migration doc
alicefr Oct 9, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
27 changes: 26 additions & 1 deletion docs/storage/volume_migration.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,4 +1,4 @@
# Migration update volume strategy and volume migration
# Update volume strategy and volume migration

Storage migration is possible while the VM is running by using the update volume strategy. Storage migration can be useful in the cases where the users need to change the underlying storage, for example, if the storage class has been deprecated, or there is a new more performant driver available.

Expand Down Expand Up @@ -201,6 +201,31 @@ spec:
pod: {}
```

## Volume migration cancellation

The users could, for various reasons, wish to stop and cancel the ongoing volume migration.
Migration cancellations are also handled declaratively, thus users must restore the previous set of volumes, which will be read as a cancellation for the volume update and migration.

A possible way to cancel the migration is to apply the old version of the VM declaration.

## Volume migration failure and recovery

If a volume migration fails, KubeVirt will continue to try to migrate until the volume update is cancelled. As a result, if the original failure was temporary, a subsequent migration could succeed; otherwise, KubeVirt continues to generate new migrations with exponential backoff time.

To recover from a persistent failure, users must revert the volume set to its original state, indicating the cancellation of the volume migration.

### Manual recovery required

If for any reasons the VMI disappears, then the volume migration isn't retried anymore. This might happen if the users inadvertently shutdown the VM or the VMI is accidentally deleted.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
If for any reasons the VMI disappears, then the volume migration isn't retried anymore. This might happen if the users inadvertently shutdown the VM or the VMI is accidentally deleted.
If for any reasons the VMI disappears, then the volume migration is not retried anymore. This might happen if the users inadvertently shutdown the VM or the VMI is accidentally deleted.

As a general rule we should avoid contractions in documentation.


However, in these situations, the VM spec is in an inconsistent state because the volume set contains the destination volumes but the copy wasn't successful, and users could fail to boot correctly the VM. For this reason the VM is marked with the condition `ManualRecoveryRequired` and KubeVirt will refuse to start a VM which has this condition.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
However, in these situations, the VM spec is in an inconsistent state because the volume set contains the destination volumes but the copy wasn't successful, and users could fail to boot correctly the VM. For this reason the VM is marked with the condition `ManualRecoveryRequired` and KubeVirt will refuse to start a VM which has this condition.
However, in these situations, the VM spec is in an inconsistent state because the volume set contains the destination volumes but the copy was not successful, and users could fail to boot correctly the VM. For this reason the VM is marked with the condition `ManualRecoveryRequired` and KubeVirt will refuse to start a VM which has this condition.


In order to recover the VM spec, the users need to revert the volume set in the VM spec as it is the case for the volume migration cancellation.

The volume migration information is stored in the VM status as well, and the users can see the full list of the migrated volumes which contain the source and destination names as well as the corresponding volume name .
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The volume migration information is stored in the VM status as well, and the users can see the full list of the migrated volumes which contain the source and destination names as well as the corresponding volume name .
The volume migration information is stored in the VM status as well, and the users can see the full list of the migrated volumes which contain the source and destination names as well as the corresponding volume name.


Users can find the whole list of migrated volumes in the VM status, which includes the source and destination names together with the associated volume name.

## Limitations

Only certain types of disks and volumes are supported to be migrated. For an invalid type of volume the RestartRequired condition is set and volumes will be replaced upon VM restart.
Expand Down