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

[Gary R Hook]

On 12/24/14 4:42 AM, Kashyap Chamarthy wrote:
> On Tue, Dec 23, 2014 at 12:38:57PM -0600, Gary R Hook wrote:
>
> [. . .]
>
> In my case, the block device is a QCOW2 disk image file. If I boot
> without using the disk image file which has the operating system, the
> domain will fail to boot, no?
>
> I see you're playing with NBD disks. I'll admit, I haven't played much
> with QEMU NBD, will have to experiment post holidays.

Back from the holidays, and back on this issue. I've learned a lot.

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, 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
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.

I can take the qcow2 file that belongs to the domain and serve it up via 
NBD:

qemu-nbd --partition=1 -p11112 /path/to/my/qcow2/file.qcow2
nbd-client localhost 11112 /dev/nbd2
mount /dev/nbd2 -oloop /mnt/foo

and lo! in /mnt/foo I found my root filesytem. Seems perfectly reasonable.

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

[1]+  Exit 1                  qemu-nbd --partition=1 -p11112 
$PWD/dsk.test.qcow2
# qemu-nbd --partition=0 -p11112 $PWD/dsk.test.qcow2 &
[1] 7686
# qemu-nbd: Invalid partition 0
^C
[1]+  Exit 1                  qemu-nbd --partition=0 -p11112 
$PWD/dsk.test.qcow2
# qemu-nbd --partition=2 -p11112 $PWD/dsk.test.qcow2 &
[1] 7699
# qemu-nbd: Could not find partition 2: Invalid argument
^C
[1]+  Exit 1                  qemu-nbd --partition=2 -p11112 
$PWD/dsk.test.qcow2
# qemu-nbd --partition=3 -p11112 $PWD/dsk.test.qcow2 &
[1] 7830
# qemu-nbd: Could not find partition 3: Invalid argument

[1]+  Exit 1                  qemu-nbd --partition=3 -p11112 
$PWD/dsk.test.qcow2

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.

So yes, blockcopy works fine under certain conditions. But the NBD layer 
seems to really muck things up.

Or, more likely, I'm doing things wrong. I'm hoping someone can point 
out something obvious.

There's a recent thread about "Block Replication for Continuous 
Checkpointing" that is heading towards using NBD. I fail to understand 
how this is ever going to work, based on my explorations.


--
Gary R Hook
Senior Kernel Engineer
NIMBOXX, Inc