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: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v4 0/6] Efficient VM backup for qemu
Date: Fri, 22 Feb 2013 11:39:14 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 22.02.2013 um 11:31 hat Stefan Hajnoczi geschrieben:
> On Thu, Feb 21, 2013 at 03:56:15PM +0000, Dietmar Maurer wrote:
> > > On Wed, Feb 20, 2013 at 04:04:49PM +0000, Dietmar Maurer wrote:
> > > > > 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.
> > > >
> > > > backup needs to work on non-seekable pipes.
> > > 
> > > In _your_ use case. That means that we should support using non-seekable
> > > pipes, but it doesn't mean that any other use case is irrelevant. In fact 
> > > I think
> > > backing up to a normal raw or qcow2 image file is the interesting case 
> > > for the
> > > majority of people.
> > 
> > VMs can have more than one disk. How do you backup them into a single raw 
> > or qcow2 image?
> > And where do you store the configuration inside a qcow2 file?
> 
> Here is a draft showing how your backup block job can be used for your
> VMA use case, as well as other use cases:

I agree with most of what you say, with one exception:

> I added the 'wait-for' attribute which tells QMP transaction to let the
> migration action complete first before doing the backup block job.  This
> way we first live migration VM state to vmstate.bin and then atomically
> kick off the backup block job - with consistent disk state.

I'm not sure if this really belongs in qemu. The management tool can
wait for the migration completed event, after which the VM will be
automatically stopped, do the snapshot and then continue the VM. This
is, as far as I know, the approach that libvirt takes today.

Kevin



reply via email to

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