Re: qemu-rbd : savevm monitor command don't save vmstate, is it normal ?

[Josh Durgin <josh.durgin@inktank.com>]

On 08/29/2012 09:25 AM, Yehuda Sadeh wrote:
> On Wed, Aug 29, 2012 at 9:15 AM, Josh Durgin <josh.durgin@inktank.com> wrote:
>> On 08/29/2012 06:40 AM, Alexandre DERUMIER wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to take a full vm state snapshot with savevm monitor command
>>> (qemu 0.12rc1 + rbd 0.48.1)
>>>
>>> it seem that vmstate is not saved in the snapshot. (I also don't notice
>>> any vm hang during snapshot)
>>> Snapshot of disk is correctly made.
>>
>>
>> AFAIK the only block backend that supports saving the vmstate is qcow2.
>> For rbd, the savevm/loadvm monitor commands are equivalent to
>> 'rbd snap create' and 'rbd snap rollback'. They just save/rollback the
>> disk.
>>
>>
>>> using loadvm monitor command, rollback correctly to disk snapshot but vm
>>> hang.
>>
>>
>> If you don't quiesce i/o i.e. via xfsfreeze (it works on the vfs level
>> now, so it's not xfs-specific anymore) before snapshotting a running
>> vm, the fs might require a fsck to be usable. This is only rolling back
>> the disk, and not the memory state, so doing it while the vm is running
>> is likely to cause problems.
>>
>>
>>> starting qemu with -loadvm snapshotname give
>>> kvm: Error -22 while loading VM state
>>>
>>>
>>> Is it normal ? Not implemented ?
>>
>>
>> bdrv_{save|load}_vmstate are not implemented.
>>
> How complicated would it be to implement it? Looking at the api it
> seems trivial. We can add a new block with a .vmstate prefix and keeps
> the raw data on it. We should probably add some librbd functionality
> that stores and retrieves alternative data payloads and use it for
> that.
>
> Yehuda
>

We probably wouldn't want to keep it in a single object, since it could
be very large, but it wouldn't be hard to reuse the regular I/O code to
stripe it across objects as well. It wouldn't be very complicated to
implement.

Josh