qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH V1 05/32] savevm: QMP command for cprload


From: Steven Sistare
Subject: Re: [PATCH V1 05/32] savevm: QMP command for cprload
Date: Thu, 24 Sep 2020 17:49:58 -0400
User-agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.0

On 9/11/2020 1:18 PM, Dr. David Alan Gilbert wrote:
> * Steven Sistare (steven.sistare@oracle.com) wrote:
>> On 7/30/2020 12:14 PM, Eric Blake wrote:
>>> On 7/30/20 10:14 AM, Steve Sistare wrote:
>>>> Provide the cprload QMP command.  The VM is created from the file produced
>>>> by the cprsave command.  Guest RAM is restored in-place from the shared
>>>> memory backend file, and guest block devices are used as is.  The contents
>>>> of such devices must not be modified between the cprsave and cprload
>>>> operations.  If the VM was running at cprsave time, then VM execution
>>>> resumes.
>>>
>>> Is it always wise to unconditionally resume, or might this command need an 
>>> additional optional knob that says what state (paused or running) to move 
>>> into?
>>
>> This can already be done.  Issue a stop command before cprsave, then cprload 
>> will finish in a
>> paused state.
>>
>> Also, cprsave re-execs and leaves the guest in a paused state.  One can
>>
>> send device add commands, then send cprload which continues
>> .
> 
> You're suffering here because you're reinventing stuff rather than
> reusing existing migration paths.
> With the existing migration code we require the qemu
> to be started with -incoming ... so we know it's in a clean
> state ready for being loaded, and we've already got the -S
> mechanism that dictates whether or not the VM autostarts
> (regardless of the saved state in the image).  The management
> layers find this pretty useful if they need to wire some networking
> or storage up at the point they know they've got a VM image that's
> loaded OK.

I am not seeing the issue here.  The manager can hot plug with cprsave as
easily as with migration, at the same transition points.  I don't see what
migration paths should be reused here.

CPR                                     Migration

- cprsave restarts qemu with the env    - qemu -S -incoming defer
var QEMU_START_FREEZE set, which
clears autostart just like -S.
(see patch 15)

- command-line devices created          - command-line devices created

- vmstate is prelaunch                  - vmstate is inmigrate

- manager sends hotplug commands        - manager sends hotplug commands

- manager sends cprload                 - manager sends migrate_incoming

It would perhaps be more correct for cprsave to leave the vm in the preconfig
state.

I don't feel like I'm suffering.  At least not yet :)

- Steve

>>>> Syntax:
>>>>    {'command':'cprload', 'data':{'file':'str'}}
>>>>
>>>> Signed-off-by: Steve Sistare <steven.sistare@oracle.com>
>>>> Signed-off-by: Maran Wilson <maran.wilson@oracle.com>
>>>> ---
>>>
>>>> +++ b/qapi/migration.json
>>>> @@ -1635,3 +1635,14 @@
>>>>   ##
>>>>   { 'command': 'cprsave', 'data': { 'file': 'str', 'mode': 'str' } }
>>>>   +##
>>>> +# @cprload:
>>>> +#
>>>> +# Start virtual machine from checkpoint file that was created earlier 
>>>> using
>>>> +# the cprsave command.
>>>> +#
>>>> +# @file: name of checkpoint file
>>>> +#
>>>> +# Since 5.0
>>>
>>> another 5.2 instance. I'll quit pointing it out for the rest of the series.
>>
>> Will find and fix all, thanks.
>>
>> - Steve
>>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]