From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:58840) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9N3x-0002GT-Jo for qemu-devel@nongnu.org; Thu, 08 Jan 2015 19:04:26 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9N3u-0003ei-BX for qemu-devel@nongnu.org; Thu, 08 Jan 2015 19:04:25 -0500 Received: from mail-ob0-x22f.google.com ([2607:f8b0:4003:c01::22f]:51821) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9N3u-0003ee-5h for qemu-devel@nongnu.org; Thu, 08 Jan 2015 19:04:22 -0500 Received: by mail-ob0-f175.google.com with SMTP id wp4so10834445obc.6 for ; Thu, 08 Jan 2015 16:04:21 -0800 (PST) Message-ID: <54AF1B04.6080704@gmail.com> Date: Thu, 08 Jan 2015 18:04:20 -0600 From: Gary R Hook MIME-Version: 1.0 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> <20150108202140.GL22477@tesla.redhat.com> In-Reply-To: <20150108202140.GL22477@tesla.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit 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: Kashyap Chamarthy Cc: libvirt-users@redhat.com, qemu-devel@nongnu.org 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