Clarify policy on migration #5914
Replies: 3 comments 3 replies
-
Clarification: Qemu has a concept of machine type which has a version associated with it. So you can do migration or save+restore on different Qemu versions as long as machine type remains the same. E.g. qemu version 8.0 running machine type Here I think firecracker provides more flexibility as later versions of firecracker can restore VMs created by an older firecracker and then you can conceivably perform a save of the VM on the new version of firecracker again thus providing an "upgrade path". |
Beta Was this translation helpful? Give feedback.
-
We have all the infrastructure in place to support migration from older version to a newer version - however we don't currently guarantee that works. |
Beta Was this translation helpful? Give feedback.
-
Closing this discussion. When the project is ready to commit to N -> N+1 migration then an issue can be created. |
Beta Was this translation helpful? Give feedback.
-
In Cloud Hypervisor, migration from a running VM to another VM is supported if they are the same major version. Migration to a different version is not supported as I understand.
This feels like a major limitation. If we're running, for example, major version
N
there should always be a migration path to at leastN+1
.Can there a clarification on what exactly is the policy of the project here ? QEMU for instance seems to go to heroic lengths to allow migration between different versions. Cloud Hypervisor should at least allow migration to the next version as a policy.
Beta Was this translation helpful? Give feedback.
All reactions