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

[Stefan Hajnoczi]

On Fri, Feb 22, 2013 at 10:14:03AM +0000, Dietmar Maurer wrote:
> > > > 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.
> 
> Is there some documentation about that NBD protocol?

See /usr/include/linux/nbd.h.  There are four commands to the protocol:

enum {
        NBD_CMD_READ = 0,
        NBD_CMD_WRITE = 1,
        NBD_CMD_DISC = 2,
        /* there is a gap here to match userspace */
        NBD_CMD_TRIM = 4
};

NBD_CMD_DISC is "disconnect".  NBD_CMD_TRIM discards regions of the
device.

The command flow is request-response.  Each request has a unique
identifier called the "handle", which allows the client to issue
multiple requests in parallel:

/*
 * This is the packet used for communication between client and
 * server. All data are in network byte order.
 */
struct nbd_request {
        __be32 magic;
        __be32 type;    /* == READ || == WRITE  */
        char handle[8];
        __be64 from;
        __be32 len;
} __attribute__((packed));

/*
 * This is the reply packet that nbd-server sends back to the client
 * after
 * it has completed an I/O request (or an error occurs).
 */
struct nbd_reply {
        __be32 magic;
        __be32 error;           /* 0 = ok, else error   */
        char handle[8];         /* handle you got
                                   from request  */
};

> > 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.
> 
> I still think using a specific protocol is wrong. You don't want to use NDB 
> if you can directly
> talk to some backup server?

NBD enables interprocess communication - any form of IPC requires a
protocol and NBD is quite a trivial one.  What is a simpler way of
talking to a backup server?

The only other vendor-independent method is writing a raw file to an
iSCSI, NFS, or CIFS export on the backup server.  QEMU also supports
that.

Those are two reasonable options, depending on whether you want to
implement a simple protocol (NBD) or you already have an existing
iSCSI/NFS/CIFS stack.

Stefan