Re: [PATCH V4 14/19] migration: cpr-transfer mode

[Markus Armbruster <armbru@redhat.com>]

Steve Sistare <steven.sistare@oracle.com> writes:

> Add the cpr-transfer migration mode.  Usage:
>
>   qemu-system-$arch -machine aux-ram-share=on ...
>
>   start new QEMU with "-incoming <main-uri> -incoming <cpr-channel>"
>
>   Issue commands to old QEMU:
>     migrate_set_parameter mode cpr-transfer
>
>     {"execute": "migrate", ...
>         {"channel-type": "main"...}, {"channel-type": "cpr"...} ... }

Much technical detail here that won't make sense to the reader until
further down, but next to nothing on what the thing actually
accomplishes.  Makes the commit message unnecessarily hard to
understand.  But please read on.

> The migrate command stops the VM, saves CPR state to cpr-channel, saves
> normal migration state to main-uri, and old QEMU enters the postmigrate
> state.  The user starts new QEMU on the same host as old QEMU, with the
> same arguments as old QEMU,

Any additional requirements over traditional migration?

There, "same arguments" is sufficient, but not necessary.  For instance,
changing certain backends is quite possible.

>                             plus two -incoming options.

Two -incoming options to define two migration channels, the traditional
one of MigrationChannelType "main", and an another one of
MigrationChannelType "cpr"?

>                                                          Guest RAM is
> preserved in place, albeit with new virtual addresses in new QEMU.
>
> This mode requires a second migration channel of type "cpr", in the
> channel arguments on the outgoing side, and in a second -incoming
> command-line parameter on the incoming side.
>
> Memory-backend objects must have the share=on attribute, but
> memory-backend-epc is not supported.  The VM must be started with
> the '-machine aux-ram-share=on' option, which allows anonymous
> memory to be transferred in place to the new process.  The memfds
> are kept open by sending the descriptors to new QEMU via the CPR
> channel, which must support SCM_RIGHTS, and they are mmap'd in new QEMU.
>
> The implementation splits qmp_migrate into start and finish functions.
> Start sends CPR state to new QEMU, which responds by closing the CPR
> channel.  Old QEMU detects the HUP then calls finish, which connects
> the main migration channel.
>
> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>

I'd lead with a brief explanation of the feature and its benefits.
Could steam from the cover letter like this:

  New migration mode cpr-transfer mode enables transferring a guest to a
  new QEMU instance on the same host 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.

Then talk about required special setup.  I see aux-ram-share=on.
Anything else?  Any differences between source and destination QEMU
there?

Then talk about the two channels.  First what they do, second how to
create their destination end with -incoming, third how to create their
source end with "migrate".

Finally mention whatever technical detail you believe needs mentioning
here.

[...]

> diff --git a/qapi/migration.json b/qapi/migration.json
> index a26960b..1bc963f 100644
> --- a/qapi/migration.json
> +++ b/qapi/migration.json
> @@ -614,9 +614,44 @@
>  #     or COLO.
>  #
>  #     (since 8.2)
> +#
> +# @cpr-transfer: This mode allows the user to transfer a guest to a
> +#     new QEMU instance on the same host with minimal guest pause
> +#     time, by preserving guest RAM in place, albeit with new virtual
> +#     addresses in new QEMU.
> +#
> +#     The user starts new QEMU on the same host as old QEMU, with the
> +#     the same arguments as old QEMU, plus the -incoming option.

Two of them?

> +#                                                                 The
> +#     user issues the migrate command to old QEMU, which stops the VM,
> +#     saves state to the migration channels, and enters the
> +#     postmigrate state.  Execution resumes in new QEMU.

The commit message also mentions file descriptors are migrared over.
Worth mentioning here, too?

> +#
> +#     This mode requires a second migration channel type "cpr" in the
> +#     channel arguments on the outgoing side.  The channel must be a
> +#     type, such as unix socket, that supports SCM_RIGHTS.  However,

This is vague.  Would anything but a UNIX domain socket work?

Applies to both source and destination end?

> +#     the cpr channel cannot be added to the list of channels for a
> +#     migrate-incoming command, because it must be read before new
> +#     QEMU opens a monitor.

Ugh!  Remind me, why is that the case?

> +#                            Instead, the user passes the channel as a
> +#     second -incoming command-line argument to new QEMU using JSON
> +#     syntax.
> +#
> +#     Memory-backend objects must have the share=on attribute, but
> +#     memory-backend-epc is not supported.  The VM must be started
> +#     with the '-machine aux-ram-share=on' option.

What happens when the conditions aren't met?  migrate command fails
with a useful error message?

> +#
> +#     The incoming migration channel cannot be a file type, and for
> +#     the tcp type, the port cannot be 0 (meaning dynamically choose
> +#     a port).

Which of the two channels are you discussing?

> +#
> +#     When using -incoming defer, you must issue the migrate command
> +#     to old QEMU before issuing any monitor commands to new QEMU.

I'm confused.  Not even qmp_capabilities?  Why?

> +#     However, new QEMU does not open and read the migration stream
> +#     until you issue the migrate incoming command.
> +#
> +#     (since 10.0)
>  ##
>  { 'enum': 'MigMode',
> -  'data': [ 'normal', 'cpr-reboot' ] }
> +  'data': [ 'normal', 'cpr-reboot', 'cpr-transfer' ] }
>  
>  ##
>  # @ZeroPageDetection:

[...]