qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH v4 0/6] Efficient VM backup for qemu


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH v4 0/6] Efficient VM backup for qemu
Date: Wed, 20 Feb 2013 16:16:13 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Feb 20, 2013 at 10:31:57AM +0100, Dietmar Maurer wrote:
> 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.txt contains more details.

Interesting series, the backup block job makes sense to me.  Regarding
efficiency, I think incremental backup is a must, otherwise regular
backups using this approach won't really be a win over backing files.

The backup writer abstraction is a special case interface somewhere
between an image format and live migration.  I'd prefer it if the backup
block job stuck to BlockDriverState as the destination for backup data.
Then you could save a point-in-time copy of a disk to a raw or even
qcow2 image.

The vmstate feature looks like vmsave duplication.  The problem with
vmsave is that it doesn't compose nicely with block jobs or the QMP
transaction command, which would allow you to snapshot the disks and
then capture the VM state.

How would VMA fit in if the backup block job took a BlockDriverState
destination and vmsave worked atomically with backup block jobs?  You
could have QEMU write to NBD server ports that a VMA writer process has
open.  VMA would happen outside the QEMU process.

The benefit of doing this is that the backup block job becomes a
general-purpose command and QEMU is not directly involved in capturing
guest configuration.  IMO the management tool is the correct place to
orchestrate guest restore.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]