From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tokarev Subject: Re: *terrible* speed of savevm/loadvm/delvm Date: Thu, 20 Nov 2008 22:08:52 +0300 Message-ID: <4925B5C4.1030008@msgid.tls.msk.ru> References: <491B0F4B.9060502@msgid.tls.msk.ru> <491C1E8C.3070701@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: KVM list To: Avi Kivity Return-path: Received: from hobbit.corpit.ru ([81.13.33.150]:24301 "EHLO hobbit.corpit.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755199AbYKTTIz (ORCPT ); Thu, 20 Nov 2008 14:08:55 -0500 In-Reply-To: <491C1E8C.3070701@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: 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