[Libguestfs] Point-in-time snapshots (was: Re: Inspection of disk snapshots)

[Stefan Hajnoczi]

On Thu, Mar 26, 2015 at 12:02:27AM +0100, Kashyap Chamarthy wrote:
> [Added Stefan Hajnoczi, who wrote the 'drive-backup' QMP command and
> Eric Blake.]
> 
> On Wed, Mar 25, 2015 at 07:41:23PM +0000, Richard W.M. Jones wrote:
> > On Wed, Mar 25, 2015 at 07:38:03PM +0100, Kashyap Chamarthy wrote:
> > > On Mon, Mar 23, 2015 at 10:43:30PM +0000, Richard W.M. Jones wrote:
> 
> [. . .]
> 
> > > > > If you want lightweight, consistent, point-in-time snapshots (which it
> > > > > sounds like you do), qemu has recently been adding this capability.
> 
> Yeah, I have the two-part incremental backup series from John Snow's
> (who is the author of it) git repo. But, he said one more revision is
> about to hit the list, so I held off my testing until I can cleanly test
> that series on top of current QEMU git master.
> 
> > > > > See the 'drive-backup' monitor command.  I've not tried using that 
> > > 
> > > A small QMP test for 'drive-backup': 
> > > 
> > >     https://kashyapc.fedorapeople.org/virt/test-qmp-drive-backup.txt
> > 
> > That's interesting, but even more interesting would be to see
> > drive-backup writing to NBD.
> >
> > From what I gather, drive-backup would take a nbd:... target, meaning
> > that it is the *client* (not the server). 
> 
> You're right -- the original cover letter[*] of the 'drive-backup' QEMU
> patch series that was merged says it:
> 
>     "The simplest use-case is to copy a point-in-time snapshot to a
>     local file.
> 
>     More advanced users may wish to make the target an NBD URL. The NBD
>     server listening on the other side can process the backup writes any
>     way it wishes."
> 
> > What's interesting is what you're supposed to connect to the server.
> > (Maybe I'm wrong about this however)
> 
> Yeah, I too wonder what to connect on the server side when using NBD as
> target with 'drive-backup' (taking the simple example test I pointed
> above).
> 
> 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.

Stefan

> 
> 
> [*] http://lists.nongnu.org/archive/html/qemu-devel/2013-06/msg04229.html
> 
> [**] NBD over TCP:
> 
> (1) Run an NBD server locally:
> 
>     $ qemu-nbd -f qcow2 -p10809 \
>         /var/lib/libvirt/images/cirros-0.3.3-x86_64-disk.img -t
> 
> (2) Create an overlay using the NBD server as backing file:
> 
>     $ qemu-img create -f qcow2 -F raw \
>         -o backing_file=nbd://localhost nbd-overlay1.qcow2
> 
> (3) Optionally, boot the overlay w/ a minimal CLI.
> 
>     $ qemu-system-x86_64               \
>        -nographic                      \
>        -nodefconfig                    \
>        -nodefaults                     \
>        -m 2048                         \
>        -device virtio-scsi-pci,id=scsi \
>        -device virtio-serial-pci       \
>        -serial stdio                   \
>        -drive file=./nbd-overlay1.qcow2,format=qcow2,if=virtio,cache=writeback
> 
> 
> -- 
> /kashyap
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libguestfs/attachments/20150327/ff9e7253/attachment.sig>