On 2024/08/08 19:54, Michael S. Tsirkin wrote:
On Thu, Aug 08, 2024 at 07:52:37PM +0900, Akihiko Odaki wrote:
On 2024/08/06 22:29, Michael S. Tsirkin wrote:
On Tue, Aug 06, 2024 at 04:35:44PM +0900, Akihiko Odaki wrote:
On 2024/08/05 19:08, Michael S. Tsirkin wrote:
On Mon, Aug 05, 2024 at 06:37:58PM +0900, Akihiko Odaki wrote:
If cross-migrate=off, QEMU can still migrate on the same host (checkpoint
and restart). QEMU can also migrate across hosts if the user ensures they
are on the same platform.
What is so special about checkpoint/restart? I guess we hope that
downgrades are uncommon, but they are possible...
Downgrades will not work with cross-migrate=off. Users who want downgrades
should use cross-migrate=on.
We also don't know that upgrades do not disable a feature:
can happen if e.g. there's a serious bug in the feature.
Basically, this makes the feature too fragile, in my opinion.
We can do nothing in such a case. Whether it is on a single host or multiple
hosts, we cannot support migration if features once enabled disappear.
Regards,
Akihiko Odaki
It does not follow that we have to do something, and this is something,
therefore that we have to do this.
This is just a reason not to handle checkpoint/restart any different
than any other migration.
Whethere it is checkpoint/restart or any other migration, I expect
platform features won't disappear from the host(s); we can't readily
support migration in such a situation.
When platform features won't disappear, for checkpoint/restart, we can
enable all available features without disrupting migration;
cross-migrate=off will instruct that.
However, if we are migrating a VM across hosts and the user doesn't
ensure they are on the same platform, we cannot enable platform features
even if we are sure that platform features already present on a host
won't disappear because some hosts may not have features in the first
place. We can set cross-migrate=on in such a case to disable optional
platform features.
Regards,
Akihiko Odaki
