Libguestfs - Mar 2015 - Re: Point-in-time snapshots (was: Re: Inspection of disk snapshots)

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:
> 
> [. . .]
> 
> > > This makes a copy of the whole disk image.  It's also not a
consistent
> > > (point in time) copy.
> > 
> > Oh I see that you're copying the _snapshot_ that you created with
> > libvirt; it's not a whole disk copy.  There's still not any
point in
> > doing this, and what I said below stands.
> > 
> > > > At that point I mount it through libguestfs and inspect its
content.
> > > 
> > > As long as you use the 'readonly=1' flag (which is really
*essential*,
> > > else you'll get disk corruption), you can just point
libguestfs at the
> > > base image:
> > > 
> > >   g = guestfs.GuestFS (python_return_dict=True)
> > >   g.add_drive_opts ("base_image.qcow2",
format="qcow2", readonly=1)
> > > 
> > > That also doesn't get you a consistent snapshot, but
it'll work most
> > > of the time, and give you a clear error in libguestfs when it
doesn't
> > > (and won't corrupt your base disk or anything like that,
provided
> > > you're using readonly=1).
> > > 
> > > The effect of the readonly=1 flag is to create an external
snapshot.
> > > It is roughly the equivalent of doing:
> > > 
> > >   qemu-img create -f qcow2 -b base_image snapshot.qcow2
> > >   < point libguestfs at snapshot.qcow2 >
> > > 
> > > If you want lightweight, consistent, point-in-time snapshots
(which it
> > > sounds like you do), qemu has recently been adding this
capability.
> > > 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).  What's interesting is what
you're supposed to connect to the server.  (Maybe I'm wrong about this
however)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

[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[**].



[*] 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

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