7:15 a.m.
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