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)?
Rich.
--
Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming and virtualization blog:
http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top