On 5/24/2021 6:39 AM, Dr. David Alan Gilbert wrote: > * Steven Sistare (steven.sist...@oracle.com) wrote: >> On 5/20/2021 9:13 AM, Dr. David Alan Gilbert wrote: >>> On the 'restart' branch of questions; can you explain, >>> other than the passing of the fd's, why the outgoing side of >>> qemu's 'migrate exec:' doesn't work for you? >> >> I'm not sure what I should describe. Can you be more specific? >> Do you mean: can we add the cpr specific bits to the migrate exec code? > > Yes; if possible I'd prefer to just keep the one exec mechanism. > It has an advantage of letting you specify the new command line; that > avoids the problems I'd pointed out with needing to change the command > line if a hotplug had happened. It also means we only need one chunk of > exec code.
How/where would you specify a new command line? Are you picturing the usual migration setup where you start a second qemu with its own arguments, plus a migrate_incoming option or command? That does not work for live update restart; the old qemu must exec the new qemu. Or something else? We could shoehorn cpr restart into the migrate exec path by defining a new migration capability that the client would set before issuing the migrate command. However, the implementation code would be sprinkled with conditionals to suppress migrate-only bits and call cpr-only bits. IMO that would be less maintainable than having a separate cprsave function. Currently cprsave does not duplicate any migration functionality. cprsave calls qemu_save_device_state() which is used by xen. - Steve
