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

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.