[Top][All Lists]

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

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

From: Kevin Wolf
Subject: Re: [Qemu-devel] Qemu savevm and CPU soft lockup
Date: Thu, 24 Sep 2009 15:19:00 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20090814 Fedora/3.0-2.6.b3.fc11 Thunderbird/3.0b3

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? In qcow2 a snapshot consists of some
fixed-size metadata plus the save/load_vmstate area which is just disk
space after the end of the virtual disk and could be extended in theory
until the 64 bits of the offset are used up.

I'm not sure what the internal interfaces look like and if they would
need to be changed, but for the format I don't see any problems. You
only need to set the right VM state size in the snapshot metadata when
you are done.


reply via email to

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