From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=33722 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OtFO1-0005s6-UI for qemu-devel@nongnu.org; Wed, 08 Sep 2010 03:48:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OtFNx-0002aE-1F for qemu-devel@nongnu.org; Wed, 08 Sep 2010 03:48:05 -0400 Received: from mx1.redhat.com ([209.132.183.28]:32434) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OtFNw-0002a7-Pz for qemu-devel@nongnu.org; Wed, 08 Sep 2010 03:48:01 -0400 Message-ID: <4C873FBD.3070205@redhat.com> Date: Wed, 08 Sep 2010 09:48:13 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] qed: Add QEMU Enhanced Disk format References: <1283767478-16740-1-git-send-email-stefanha@linux.vnet.ibm.com> <4C86A393.8000109@codemonkey.ws> In-Reply-To: <4C86A393.8000109@codemonkey.ws> 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: Anthony Liguori Cc: Blue Swirl , Stefan Hajnoczi , qemu-devel@nongnu.org Am 07.09.2010 22:41, schrieb Anthony Liguori: > There's two types of snapshots that I think can cause confusion. > There's CPU/device state snapshots and then there's a block device snapshot. > > qcow2 and qed both support block device snapshots. qed only supports > external snapshots (via backing_file) whereas qcow2 supports external > and internal snapshots. The internal snapshots are the source of an > incredible amount of complexity in the format. > > qcow2 can also store CPU/device state snapshots and correlate them to > block device snapshots (within a single block device). It only supports > doing non-live CPU/device state snapshots. Which is not a property of the format, but of the implementation. I think it shouldn't be too hard to introduce live snapshots. > OTOH, qemu can support live snapshotting via live migration. Today, it > can be used to snapshot CPU/device state to a file on the filesystem > with minimum downtime. > > Combined with an external block snapshot and correlating data, this > could be used to implement a single "snapshot" command that would behave > like savevm but would not pause a guest's execution. We'd need fields for referencing a VM state file from a QED image, just like it's already done for backing files. Kevin