[libvirt-users] Using virsh blockcopy -- what's it supposed to accomplish?
Gary R Hook
grhookatwork at gmail.com
Fri Jan 9 00:04:20 UTC 2015
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
More information about the libvirt-users
mailing list