From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33584 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PuLkU-0006vn-FZ for qemu-devel@nongnu.org; Tue, 01 Mar 2011 04:20:07 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PuLkT-00055X-7T for qemu-devel@nongnu.org; Tue, 01 Mar 2011 04:20:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:63648) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PuLkS-00055K-V4 for qemu-devel@nongnu.org; Tue, 01 Mar 2011 04:20:05 -0500 Message-ID: <4D6CBAB6.80108@redhat.com> Date: Tue, 01 Mar 2011 10:21:58 +0100 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [Bug 726619] [NEW] loadvm does not load (offline) snapshot anymore References: <20110228160401.29334.5055.malonedeb@wampee.canonical.com> <20110228160401.29334.5055.malonedeb@wampee.canonical.com> In-Reply-To: <20110228160401.29334.5055.malonedeb@wampee.canonical.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Bug 726619 <726619@bugs.launchpad.net> Cc: qemu-devel@nongnu.org Am 28.02.2011 17:04, schrieb Ralf Haferkamp: > Public bug reported: > > qemu Version: 0.14.0 > The problem is present in the current code from git master as well. > > Loading a snapshot that was created while qemu was not running (using > qemu-img) does not seem to work anymore. Is there even a use case for this? While an OS is running, just silently replacing the disk contents isn't going to work. And if you're rebooting anyway, you can as well load the snapshot offline. > Using "loadvm " in the qemu monitor does not have the > desired effect. Not even an error message is displayed. > > I was able to track down the problem (using git bisect) to this commit: > http://git.qemu.org/qemu.git/commit/?id=f0aa7a8b2d518c54430e4382309281b93e51981a > > After reverting that commit in my local git checkout everything is > workin as expected again. In fact, that commit only lets loadvm fail earlier. Before, loadvm would have loaded all disk snapshots and then returned -EINVAL because there was no VM state, now it fails immediately (the VM is stopped in both cases because of the failure). I think the correct fix is to add an error message. Kevin