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.
--
Gary R Hook
Senior Kernel Engineer
NIMBOXX, Inc