From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47108) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdI8H-0003za-JT for qemu-devel@nongnu.org; Tue, 27 Nov 2012 05:11:19 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TdI8A-000879-N0 for qemu-devel@nongnu.org; Tue, 27 Nov 2012 05:11:13 -0500 Received: from e23smtp05.au.ibm.com ([202.81.31.147]:57503) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TdI89-00086e-UG for qemu-devel@nongnu.org; Tue, 27 Nov 2012 05:11:06 -0500 Received: from /spool/local by e23smtp05.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 27 Nov 2012 20:08:36 +1000 Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id qARAAtBG58523856 for ; Tue, 27 Nov 2012 21:10:55 +1100 Received: from d23av02.au.ibm.com (loopback [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id qARAAtNM014489 for ; Tue, 27 Nov 2012 21:10:55 +1100 Message-ID: <50B4916D.40909@linux.vnet.ibm.com> Date: Tue, 27 Nov 2012 18:09:49 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <1353488464-82756-1-git-send-email-dietmar@proxmox.com> In-Reply-To: <1353488464-82756-1-git-send-email-dietmar@proxmox.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH 1/5] RFC: Efficient VM backup for qemu (v1) List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Dietmar Maurer Cc: kwolf@redhat.com, qemu-devel@nongnu.org ÓÚ 2012-11-21 17:01, Dietmar Maurer дµÀ: > This series provides a way to efficiently backup VMs. > > * Backup to a single archive file > * Backup contain all data to restore VM (full backup) > * Do not depend on storage type or image format > * Avoid use of temporary storage > * store sparse images efficiently > > The file docs/backup-rfc.txt contains more details. > > Signed-off-by: Dietmar Maurer > --- > docs/backup-rfc.txt | 119 +++++++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 119 insertions(+), 0 deletions(-) > create mode 100644 docs/backup-rfc.txt > > diff --git a/docs/backup-rfc.txt b/docs/backup-rfc.txt > new file mode 100644 > index 0000000..5b4b3df > --- /dev/null > +++ b/docs/backup-rfc.txt > @@ -0,0 +1,119 @@ > +RFC: Efficient VM backup for qemu > + > +=Requirements= > + > +* Backup to a single archive file > +* Backup needs to contain all data to restore VM (full backup) > +* Do not depend on storage type or image format > +* Avoid use of temporary storage > +* store sparse images efficiently > + > +=Introduction= > + > +Most VM backup solutions use some kind of snapshot to get a consistent > +VM view at a specific point in time. For example, we previously used > +LVM to create a snapshot of all used VM images, which are then copied > +into a tar file. > + > +That basically means that any data written during backup involve > +considerable overhead. For LVM we get the following steps: > + > +1.) read original data (VM write) > +2.) write original data into snapshot (VM write) > +3.) write new data (VM write) > +4.) read data from snapshot (backup) > +5.) write data from snapshot into tar file (backup) > + > +Another approach to backup VM images is to create a new qcow2 image > +which use the old image as base. During backup, writes are redirected > +to the new image, so the old image represents a 'snapshot'. After > +backup, data need to be copied back from new image into the old > +one (commit). So a simple write during backup triggers the following > +steps: > + > +1.) write new data to new image (VM write) > +2.) read data from old image (backup) > +3.) write data from old image into tar file (backup) > + > +4.) read data from new image (commit) > +5.) write data to old image (commit) > + > +This is in fact the same overhead as before. Other tools like qemu > +livebackup produces similar overhead (2 reads, 3 writes). > + > +Some storage types/formats supports internal snapshots using some kind > +of reference counting (rados, sheepdog, dm-thin, qcow2). It would be possible > +to use that for backups, but for now we want to be storage-independent. > + > +Note: It turned out that taking a qcow2 snapshot can take a very long > +time on larger files. > + > +=Make it more efficient= > + > +The be more efficient, we simply need to avoid unnecessary steps. The > +following steps are always required: > + > +1.) read old data before it gets overwritten > +2.) write that data into the backup archive > +3.) write new data (VM write) > + > +As you can see, this involves only one read, an two writes. > + > +To make that work, our backup archive need to be able to store image > +data 'out of order'. It is important to notice that this will not work > +with traditional archive formats like tar. > + > +During backup we simply intercept writes, then read existing data and > +store that directly into the archive. After that we can continue the > +write. > + > +==Advantages== > + > +* very good performance (1 read, 2 writes) > +* works on any storage type and image format. > +* avoid usage of temporary storage > +* we can define a new and simple archive format, which is able to > + store sparse files efficiently. > + > +Note: Storing sparse files is a mess with existing archive > +formats. For example, tar requires information about holes at the > +beginning of the archive. > + > +==Disadvantages== > + > +* we need to define a new archive format > + > +Note: Most existing archive formats are optimized to store small files > +including file attributes. We simply do not need that for VM archives. > + > +* archive contains data 'out of order' > + > +If you want to access image data in sequential order, you need to > +re-order archive data. It would be possible to to that on the fly, > +using temporary files. > + > +Fortunately, a normal restore/extract works perfectly with 'out of > +order' data, because the target files are seekable. > + > +* slow backup storage can slow down VM during backup > + > +It is important to note that we only do sequential writes to the > +backup storage. Furthermore one can compress the backup stream. IMHO, > +it is better to slow down the VM a bit. All other solutions creates > +large amounts of temporary data during backup. > + > +=Archive format requirements= > + > +The basic requirement for such new format is that we can store image > +date 'out of order'. It is also very likely that we have less than 256 > +drives/images per VM, and we want to be able to store VM configuration > +files. > + > +We have defined a very simply format with those properties, see: > + > +docs/specs/vma_spec.txt > + > +Please let us know if you know an existing format which provides the > +same functionality. > + > + > Just want to confirm something to understand it better: you are backing up the block image not including VM memory state right? I am considering a way to do live Savevm including memory and device state, so wonder if you already had a solution for it. -- Best Regards Wenchao Xia