On Fri, Mar 27, 2015 at 03:35:02PM +0000, Richard W.M. Jones wrote: > On Fri, Mar 27, 2015 at 03:21:25PM +0000, Stefan Hajnoczi wrote: > > On Fri, Mar 27, 2015 at 12:31:41PM +0000, Richard W.M. Jones wrote: > > > On Fri, Mar 27, 2015 at 12:15:34PM +0000, Stefan Hajnoczi wrote: > > > > On Thu, Mar 26, 2015 at 12:02:27AM +0100, Kashyap Chamarthy wrote: > > > > > So, something like? > > > > > > > > > > . . . > > > > > { 'execute': 'drive-backup', 'arguments': > > > > > { 'device': 'drive-virtio-disk1', 'sync': 'full', 'target': > > > > > 'nbd://localhost', 'mode': 'absolute-paths', 'format': > > > > > 'qcow2' } > > > > > . . . > > > > > > > > > > Same question as yours, what is the NBD server going to run? > > > > > > > > > > > > > > > My only NBD testing so far has been with w/ NBD over Unix socket or > > > > > over TCP[**]. > > > > > > > > For 'sync': 'full' mode qemu-nbd or nbd-server can be used as the > > > > server. You probably don't want 'format': 'qcow2', just raw data over > > > > NBD. That way the NBD server can implement whatever storage backend it > > > > likes (raw, qcow2, something else). > > > > > > > > For incremental backup the NBD server would either be a qemu-nbd > > > > instance with a qcow2 image and backing file: > > > > > > > > full-backup.img <- incremental-1.qcow2 <- incremental-2.qcow2 > > > > > > > > Or the NBD server would be a custom backup application that does > > > > something smart with the incoming NBD WRITE requests. > > > > > > What I care about is connecting libguestfs to qemu and reading a > > > snapshot at some point in time, even though the guest is still writing > > > away to its disks. Is this possible with drive-backup (or otherwise)? > > > > Yes, that is what drive-backup does. > > > > New writes coming from the guest are held up until the old data has been > > written to the NBD target. > > > > That way you get a point-in-time snapshot while the guest continues > > running. > > I understand how that can work for backups, where you want to copy > a whole disk consistently. > > But libguestfs doesn't want to do a backup, nor get a copy of the > whole disk, it just wants to access a scattering of blocks (maybe a > few hundred) but at a single point in time, in as lightweight a manner > as possible.
There is a way to do that. Create a temporary qcow2 backed by the disk: guest.img <- tmp.qcow2 Now use drive-backup with sync mode 'none' so only new guest writes cause old data to be stashed in tmp.qcow2 before it is overwritten. Finally, use the run-time NBD server for random access to tmp.qcow2. When you are done, kill the drive-backup job and delete tmp.qcow2. Stefan
pgpF25HsTIKYo.pgp
Description: PGP signature
_______________________________________________ Libguestfs mailing list Libguestfs@redhat.com https://www.redhat.com/mailman/listinfo/libguestfs