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
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
