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

On 1/8/15 2:21 PM, Kashyap Chamarthy wrote: >>qemu-img create -f qcow2 /tmp/dsk.test.qcow2 > >A typo? You also need to provide a size here: > > $ qemu-img create -f qcow2 /tmp/dsk.test.qcow2 1G Yes, my mistake. The size is set to the potential size of the source disk, which in this case is 20G. >For the rest, I'm afraid I still didn't manage time to test >the NBD scenario to give a meaningful response here. I'll let the others >who deal with NBD more often respond to it. Well, that's the trick, right? No one that may have any experience has managed to pitch in to this conversation. I can add this now: qemu-nbd seems to function like nbd-server, and concern itself with serving a filesystem. What's need, however, is a simple _file_. The challenge is getting that NBD-served thing to be viewed the same as a local disk file. It would appear that the virsh option --raw is required. As far as I can tell, both virsh and qemu-nbd munge data with the intent of making it suitable for a qcow2 destination; the problem is that we don't need double-munging. So telling the blockcopy operation to "knock it off" seems to make it treat the NBD device the same as it does a simple disk file. Yea! So I find that the following: >>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 only requires the addition of "--raw" to the above command. Or, rather, what I really need, which is virsh blockcopy --domain my_domain --raw which I can then control with subsequent commands.

I'm kinda surprised no one else has tried to do this and lived to write about it.