On 2024/08/08 20:12, Michael S. Tsirkin wrote:
On Thu, Aug 08, 2024 at 08:03:25PM +0900, Akihiko Odaki wrote:
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.
We can if we mask the features from the guest before starting VM.
Or if we didn't, we can fail gracefully.
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
This is too big of a hammer. People already use what you call "cross
migrate" and have for years. We are not going to stop developing
features just because someone suddenly became aware of some such bit.
If you care, you will have to work to solve the problem properly -
nacking half baked hacks is the only tool maintainers have to make
people work on hard problems.
I think you meant cross-migrate=off, which is the current behavior.
I am not suggesting forcing cross-migrate=on or even making it default.
I have shown four possible scenarios earlier[a]:
1) Migration everywhere
2) Migration on specific machines
3) Migration on some known platforms
4) No migration (migration on nowhere)
Taking the discussion with Peter, I amend 4) as follows:
4*) Migration on one platform (checkpoint/restore)
cross-migrate=on is a complete solution for 1).
2) is dealt with another proposal of mine.[b]
3) can be solved with the -platform proposal by Daniel.[c]
4*) is what QEMU currently implements.
[a]
https://lore.kernel.org/all/39a8bb8b-4191-4f41-aaf7-06df24bf3...@daynix.com/
[b]
https://lore.kernel.org/all/2da4ebcd-2058-49c3-a4ec-8e60536e5...@daynix.com/
[c] https://lore.kernel.org/all/zqo7cr-uigpx2...@redhat.com/
Regards,
Akihiko Odaki
