Avi Kivity wrote Thu, 13 Nov 2008 14:33:16 +0200:
> Michael Tokarev wrote:
>> Somewhere between kvm-75 and kvm-78, the
>> mentioned commands has been slowed down
>> to insane levels.  By "insane" I mean to
>> take about 10 minutes(!) to save/load a
>> 128MB RAM/1GB HDD VM's state.  It used
>> to require several seconds for much larger
>> VMs...
>>
>> Here's a typical sequence of system calls
>> during savevm:
> [snip strace]
> 
>> As you see, it writes 2 bytes, llseeks to THE SAME
>> position, writes next 2 bytes and so on.  This takes
>> HUGE amount of time, and can be done, in most cases,
>> in a single write without any seeks.
>>
>> Is it just me or are savevm/loadvm/delvm really THAT
>> broken?
> 
> It's qcow2 that is broken, with the new default cache=writethrough. 
> Does cache=writeback speed things up?

Please excuse me for this long delay replying...
I tried other solutions meanwhile (migrate to exec:), but did not
succeed there either.

Well.  While with writeback mode, the speed is definitely
better.  But it is still very very slow - not THAT terrible,
but it still takes several mins to complete a 512MB VM with
a single 4Gb qcow2 file.

> This is probably block reference counts being updated.  There were some
> batching patches posted, but they have not been applied yet, and are
> probably insufficient for savevm.

Oh well.... :(

So it really is that there's no way to "freeze" a vm currently.
savevm/loadvm is too slow to be useful, and migrate does not
work with local files (yet)...

>> And since migration to disk has been removed too,
>> there's no way currently to save the VM state...
> 
> That's being restored.

Thanks!  Tried that (current patches), does not quite here yet :)

/mjt
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to