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

[Gary R Hook <grhookatwork@gmail.com>]

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.

-- 
Gary R Hook
Senior Kernel Engineer
NIMBOXX, Inc