On 15.01.24 11:48, David Hildenbrand wrote:
On 12.01.24 16:04, Steve Sistare wrote:
Allow cpr-reboot for vfio if the guest is in the suspended runstate. The
guest drivers' suspend methods flush outstanding requests and re-initialize
the devices, and thus there is no device state to save and restore. The
user is responsible for suspending the guest before initiating cpr, such as
by issuing guest-suspend-ram to the qemu guest agent.
Can you briefly explain what cpr-reboot is, or do you have a pointer to
some more details?
What is is good for, why would you use it, how does it work?
I *suspect* that you want to live-migrate a VM with vfio devices
attached, whereby you don't want to migrate device state.
Ah, found it:
+# @cpr-reboot: The migrate command saves state to a file, allowing one to
+# quit qemu, reboot to an updated kernel, and restart an updated
+# version of qemu. The caller must specify a migration URI
+# that writes to and reads from a file. Unlike normal mode,
+# the use of certain local storage options does not block the
+# migration, but the caller must not modify guest block devices
+# between the quit and restart. To avoid saving guest RAM to the
+# file, the memory backend must be shared, and the
@x-ignore-shared
+# migration capability must be set. Guest RAM must be
non-volatile
+# across reboot, such as by backing it with a dax device, but this
+# is not enforced. The restarted qemu arguments must match those
+# used to initially start qemu, plus the -incoming option.
+# (since 8.2)
I'll note that the use of "reboot" is extremely confusing in this context.
You *might* want to reboot the hypervisor, but that's actually completely
independent from the QEMU implementation.
--
Cheers,
David / dhildenb
