From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqWRW-0007DN-DC for qemu-devel@nongnu.org; Wed, 23 Sep 2009 14:19:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqWRR-0007B2-O5 for qemu-devel@nongnu.org; Wed, 23 Sep 2009 14:19:53 -0400 Received: from [199.232.76.173] (port=46341 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqWRR-0007Ap-Hw for qemu-devel@nongnu.org; Wed, 23 Sep 2009 14:19:49 -0400 Received: from mail2.shareable.org ([80.68.89.115]:53379) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MqWRR-0001R2-3W for qemu-devel@nongnu.org; Wed, 23 Sep 2009 14:19:49 -0400 Date: Wed, 23 Sep 2009 19:19:45 +0100 From: Jamie Lokier Subject: Re: [Qemu-devel] Qemu savevm and CPU soft lockup Message-ID: <20090923181945.GB23822@shareable.org> References: <1253267801.9686.159.camel@bcm-portable> <1253721904.16114.101.camel@bcm-portable> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1253721904.16114.101.camel@bcm-portable> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Benjamin Cleyet-Marrel Cc: qemu-devel@nongnu.org Benjamin Cleyet-Marrel wrote: > > Hi, > After further investigation, I figured out that when issuing a savevm > command > the entire qemu process gets stuck on IO wait. > I can't issue any other commands on the monitor the process is shown > as D and the guest is in softlockup state. > Looking at the way migrate (and the -d for detach I presume) is > working I suppose the same behaviour would be expected from the savevm > function. > A savevm -d so that the qemu process would not be freezed while saving > the data. > Sorry if I am just talking non sense but my snapshot on iscsi storage > takes about 1 minutes. > which means that my guest are down for a minute or so which is not > ideal. 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. You might avoid the guest softlockup state by stopping the guest ("stop" command) before savevm, and "cont" afterwards? Or the guest might get just as confused, as the clock still advances. -- Jamie