From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9NHt-0005ev-6t for qemu-devel@nongnu.org; Thu, 08 Jan 2015 19:18:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Y9NHq-0008I5-0K for qemu-devel@nongnu.org; Thu, 08 Jan 2015 19:18:49 -0500 Received: from mail-oi0-x22b.google.com ([2607:f8b0:4003:c06::22b]:58231) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Y9NHp-0008Hz-Rr for qemu-devel@nongnu.org; Thu, 08 Jan 2015 19:18:45 -0500 Received: by mail-oi0-f43.google.com with SMTP id i138so9857207oig.2 for ; Thu, 08 Jan 2015 16:18:45 -0800 (PST) Message-ID: <54AF1E64.3000002@gmail.com> Date: Thu, 08 Jan 2015 18:18:44 -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> <54AEF0CF.1060001@redhat.com> In-Reply-To: <54AEF0CF.1060001@redhat.com> Content-Type: text/plain; charset=utf-8; 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: Eric Blake , qemu-devel@nongnu.org, libvirt-users@redhat.com On 1/8/15 3:04 PM, Eric Blake wrote: > > Where are you specifying the format? I have not personally played with > NBD much. This appears to be the pervasive situation. There's not much out there in google-land about this. > But here's my guess: Even though /tmp/dsk.test.qcow2 is a > qcow2 file, the NBD server is serving up a RAW image through /dev/nbd2. > Thus, if you are trying to treat /dev/nbd2 as the destination of your > copy, you MUST tell qemu that the file format of the copy is to be raw > (regardless of the file format of the original that is being copied > from). If you omit the --raw (also spelled --format=raw in newer > libvirt) parameter to the virsh blockcopy command, then libvirt has to > guess at the destination format; if the source was qcow2, then libvirt > will guess that the destination should be qcow2 as well. But writing > qcow2 data to a raw NBD disk means you have created a nested file in > /tmp/dsk.test.qcow2 - it is a qcow2 file whose contents are a qcow2 file > whose contents are the raw data (not typical usage, and a bit weird to > wrap your head around). Yes, I _finally_ figured all of that out this afternoon after observing that --raw seemed to get everything working. Thank you for confirming the conclusions I arrived at independently. I should turn this experience into a guest blog post, I suppose. -- Gary R Hook Senior Kernel Engineer NIMBOXX, Inc