Re: [Qemu-devel] [PATCH v4 3/6] add backup related monitor commands

[Stefan Hajnoczi]

On Thu, Feb 21, 2013 at 03:48:57PM +0000, Dietmar Maurer wrote:
> > > In future, we can allow to pass multiple config files - the vma
> > > archive format can already handle that.
> > 
> > My point is that QEMU has no business dealing with the management tool's VM
> > configuration file.  And I think the management tool-specific archive 
> > format also
> > shouldn't be in QEMU.
> > 
> > How will a proxmox user restore a VMA file generated with oVirt since the
> > configuration file comes from the management layer?  They can't because the
> > VMA is specific to the management layer and should be handled there, not 
> > inside
> > QEMU.
> 
> The management tooI just needs to convert the config - looks quite easy to me.

It's not an easy problem.  This is why there is no central vm-images.com
where everyone can share/sell virtual appliances.  You cannot trivially
convert between VMware, oVirt, proxmox, Xen, EC2, etc.

> > QEMU must provide the mechanism for point-in-time backups of block devices -
> > your backup block job implements this.
> > 
> > Where I disagree with this patch series is that you put the management tool-
> > specific archive format writer into QEMU.  That is outside the scope of 
> > QEMU.
> > The management tool should tell QEMU to take the backups of block devices
> > and do a live migration to file.
> > 
> > The management tool can use a NBD server if it wants to capture all the 
> > block
> > device backups into a single archive.  And the management tool can bundle 
> > the
> > VM configuration into that archive too.  But those steps are beyond the 
> > scope of
> > QEMU.
> > 
> > The approach I'm suggesting is more modular.  For example, the backup block
> > job can also be used to copy out the state of a disk into a new
> > qcow2 file.
> 
> OK, I can try to split the code. But I think I will simply define a 
> 'protocol' instead
> of using an NBD server (what for?)

block/nbd.c already exists so it saves you from writing the QEMU-side
code to export data to another process.

The archive writer program opens a listen socket for each block device
that is being backed up.  Then it handles NBD WRITE requests from QEMU.

> > > > > diff --git a/qmp-commands.hx b/qmp-commands.hx index
> > > > > 799adea..17e381b
> > > > > 100644
> > > > > --- a/qmp-commands.hx
> > > > > +++ b/qmp-commands.hx
> > > > > @@ -889,6 +889,18 @@ EQMP
> > > > >      },
> > > > >
> > > > >      {
> > > > > +        .name       = "backup",
> > > > > +        .args_type  = "backup-file:s,format:s?,config-
> > file:F?,speed:o?,devlist:s?",
> > > > > +        .mhandler.cmd_new = qmp_marshal_input_backup,
> > > > > +    },
> > > > > +
> > > > > +    {
> > > > > +        .name       = "backup-cancel",
> > > > > +        .args_type  = "",
> > > > > +        .mhandler.cmd_new = qmp_marshal_input_backup_cancel,
> > > > > +    },
> > > >
> > > > We might want to more than one backup if the guest has multiple disks.
> > > > For example, the database disk is backed up independently of the main OS
> > disk.
> > > >
> > > > This API only allows one backup to run at a time.
> > >
> > > I do not want multiple backup jobs. You can easily run 2 jobs in sequence 
> > > to
> > solve above use case.
> > 
> > Why do you not want multiple backup jobs?  It makes perfect sense to 
> > separate
> > database disks from main OS disks.  They have different backup 
> > characteristics
> > (how often to back up, how to restore) so it's likely that users will ask 
> > for
> > multiple backup jobs at the same time.  Let's get the QMP interfaces right 
> > so that
> > it can be supported in the future, if not right away.
> 
> So you want to pass the 'uuid' to backup-cancel?

Yes, that works.  Or let the user specify the ID for this backup job.
That way the management tool can use its own IDs.  QEMU doesn't care, it
treats the IDs as opaque strings.

Stefan