Re: [Qemu-devel] [libvirt-users] Using virsh blockcopy -- what's it supposed to accomplish?

[Eric Blake]

On 01/08/2015 12:44 PM, Gary R Hook wrote:
> I've learned how to use the blockcopy command to create a local copy in
> a simple disk file:
> 
> virsh dumpxml my_domain > my_domain.xml
> virsh undefine my_domain
> virsh blockcopy --domain my_domain vda $PWD/dsk.copy.qcow2 --wait
> --verbose  --finish
> virsh define my_domain.xml
> 
> and the resulting copy in dsk.copy.qcow2 is, indeed, bootable. It
> appears to be a perfect copy, as I expect it to be.
> 
> But while I see (per Kashyap's article, etc) that it can be useful in
> certain scenarios, it's not interesting to me. I would like to my copy
> to be off-system,

Once you have the local dsk.copy.qcow2, you can then move it off-system
and serve it up however you'd like, including by NBD.

> and was hoping to use the NBD interface to accomplish
> that. So I tried this (a variant of the above), working on the same
> system because it's easier:
> 
> qemu-img create -f qcow2 /tmp/dsk.test.qcow2
> qemu-nbd -f qcow2 -p11112 /tmp/dsk.test.qcow2
> nbd-client localhost 11112 /dev/nbd2
> virsh dumpxml my_domain > my_domain.xml
> virsh undefine my_domain
> virsh blockcopy --domain my_domain --wait --verbose --finish

Missing a destination?  I'm guessing you meant /dev/nbd2 as the
pre-existing destination?

> virsh define my_domain.xml
> nbd-client -d /dev/nbd2
> 
> and the qemu-nbd process exits, as I wish. I presume at this point that
> the new file has integrity.

Where are you specifying the format?  I have not personally played with
NBD much.  But here's my guess: Even though /tmp/dsk.test.qcow2 is a
qcow2 file, the NBD server is serving up a RAW image through /dev/nbd2.
 Thus, if you are trying to treat /dev/nbd2 as the destination of your
copy, you MUST tell qemu that the file format of the copy is to be raw
(regardless of the file format of the original that is being copied
from).  If you omit the --raw (also spelled --format=raw in newer
libvirt) parameter to the virsh blockcopy command, then libvirt has to
guess at the destination format; if the source was qcow2, then libvirt
will guess that the destination should be qcow2 as well.  But writing
qcow2 data to a raw NBD disk means you have created a nested file in
/tmp/dsk.test.qcow2 - it is a qcow2 file whose contents are a qcow2 file
whose contents are the raw data (not typical usage, and a bit weird to
wrap your head around).

> 
> If, however, I try to use my generated-via-NBD file, I get this:
> 
> # qemu-nbd --partition=1 -p11112 $PWD/dsk.test.qcow2 &
> [1] 7672
> # qemu-nbd: Could not find partition 1: Invalid argument

It goes back to your format nesting mistake above - you are serving up a
nested qcow2 image rather than raw data, while the guest is trying to
treat the served up image as data.  Since the nested qcow2 data in
sector 0 of the served-up data is not a partition table, it is no wonder
that you can't find a partition.

> 
> I don't know what has been created, but it's not a copy of the original
> guest's disk. There's no partition there, it seems.

Or there is, but only if you peel off yet another layer of qcow2 :)

Try doing 'virsh blockcopy --raw /dev/nbd2 ...', to see if I was right
and that makes the difference.  Remember, blockcopy CAN change things so
that the destination (as seen by qemu) is a different format than the
source, and in the case of doing a blockcopy from a qcow2 source to a
raw-image NBD server, this is a case where you need to be explicit about
the difference in format.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature