[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
>>