[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH V3 00/22] Live Update [restart]
From: |
Steven Sistare |
Subject: |
Re: [PATCH V3 00/22] Live Update [restart] |
Date: |
Wed, 2 Jun 2021 09:51:30 -0400 |
User-agent: |
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2 |
On 5/24/2021 6:39 AM, Dr. David Alan Gilbert wrote:
> * Steven Sistare (steven.sistare@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