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