Steve,
On Sun, Jun 30, 2024 at 12:40:23PM -0700, Steve Sistare wrote:
What?
Thanks for trying out with the cpr-transfer series. I saw that that series
missed most of the cc list here, so I'm attaching the link here:
https://lore.kernel.org/r/1719776648-435073-1-git-send-email-steven.sistare@oracle.com
I think most of my previous questions for exec() solution still are there,
I'll try to summarize them all in this reply as much as I can.
This patch series adds the live migration cpr-exec mode, which allows
the user to update QEMU with minimal guest pause time, by preserving
guest RAM in place, albeit with new virtual addresses in new QEMU, and
by preserving device file descriptors.
The new user-visible interfaces are:
* cpr-exec (MigMode migration parameter)
* cpr-exec-command (migration parameter)
I really, really hope we can avoid this..
It's super cumbersome to pass in a qemu cmdline in a qemu migration
parameter.. if we can do that with generic live migration ways, I hope we
stick with the clean approach.
* anon-alloc (command-line option for -machine)
Igor questioned this, and I second his opinion.. We can leave the
discussion there for this one.
The user sets the mode parameter before invoking the migrate command.
In this mode, the user issues the migrate command to old QEMU, which
stops the VM and saves state to the migration channels. Old QEMU then
exec's new QEMU, replacing the original process while retaining its PID.
The user specifies the command to exec new QEMU in the migration parameter
cpr-exec-command. The command must pass all old QEMU arguments to new
QEMU, plus the -incoming option. Execution resumes in new QEMU.
Memory-backend objects must have the share=on attribute, but
memory-backend-epc is not supported. The VM must be started
with the '-machine anon-alloc=memfd' option, which allows anonymous
memory to be transferred in place to the new process.
Why?
This mode has less impact on the guest than any other method of updating
in place.
So I wonder whether there's comparison between exec() and transfer mode
that you recently proposed.
I'm asking because exec() (besides all the rest of things that I dislike on
it in this approach..) should be simply slower, logically, due to the
serialized operation to (1) tearing down the old mm, (2) reload the new
ELF, then (3) runs through the QEMU init process.
If with a generic migration solution, the dest QEMU can start running (2+3)
concurrently without even need to run (1).