From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:46477) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9Jaa-0008Ty-HM for qemu-devel@nongnu.org; Thu, 08 Jan 2015 15:21:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9JaV-00017e-UU for qemu-devel@nongnu.org; Thu, 08 Jan 2015 15:21:52 -0500 Received: from mx1.redhat.com ([209.132.183.28]:39372) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9JaV-00017S-Ms for qemu-devel@nongnu.org; Thu, 08 Jan 2015 15:21:47 -0500 Date: Thu, 8 Jan 2015 21:21:40 +0100 From: Kashyap Chamarthy Message-ID: <20150108202140.GL22477@tesla.redhat.com> References: <54989AB7.7050607@gmail.com> <5498A052.8060904@redhat.com> <20141223121708.GB24588@tesla.redhat.com> <5499B6C1.2060601@gmail.com> <20141224104226.GE24588@tesla.redhat.com> <54AEDE3A.9040404@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54AEDE3A.9040404@gmail.com> Subject: Re: [Qemu-devel] [libvirt-users] Using virsh blockcopy -- what's it supposed to accomplish? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gary R Hook Cc: libvirt-users@redhat.com, qemu-devel@nongnu.org On Thu, Jan 08, 2015 at 01:44:58PM -0600, Gary R Hook wrote: > 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 Yes, that's correct. > and the resulting copy in dsk.copy.qcow2 is, indeed, bootable. It appears to > be a perfect copy, as I expect it to be. Good, this time you find it bootable, compared to your previous test. > 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 A typo? You also need to provide a size here: $ qemu-img create -f qcow2 /tmp/dsk.test.qcow2 1G 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. > 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. -- /kashyap