Re: [Qemu-devel] Qemu savevm and CPU soft lockup

[Kevin Wolf <kwolf@redhat.com>]

Am 24.09.2009 18:20, schrieb Anthony Liguori:
> Kevin Wolf wrote:
>> Am 24.09.2009 00:28, schrieb Anthony Liguori:
>>   
>>> Jamie Lokier wrote:
>>>     
>>>> This is normal savevm behaviour, and it is exactly the reason why
>>>> migrate-to-file is useful.  I would not be surprised if savevm is
>>>> changed to use migrate-to-file internally at some point, but it does
>>>> not look like happening soon.
>>>>   
>>>>       
>>> It's the same infrastructure.  The reason savevm isn't live is that 
>>> savevm stores it's data in a qcow2 file.  Right now the way qcow2 is 
>>> structured, the snapshot has to be a fixed size and allocated at once.  
>>> In order to make savevm live, we need a method to stream savevm data to 
>>> a qcow2 file while still allowing other IO operations to that qcow2 file.
>>>
>>> I'm fairly sure this will require a change to the qcow2 format in order 
>>> to support this.
>>>     
>>
>> Hm, snapshots are nothing complicated from qcow2 perspective. Why do you
>> think data needs to be fixed size?
> 
> What happens if you're in the middle of writing snapshot data and 
> another cluster has to be allocated?  You'll need a way to store the 
> snapshot data discontinuously.

Well, mapping virtually continuous data to discontinuous areas in the
image file is just how qcow2 works, right?

If you look at qcow_vmstate_load/save(offset), this is basically just a
call to bdrv_pread/pwrite(virtual_disk_size + offset). So for snapshots
it works exactly the same way as with regular data (which usually isn't
preallocated in qcow2 images).

Kevin