[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



[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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]