From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:59151) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLfzR-0004Da-KB for qemu-devel@nongnu.org; Tue, 09 Oct 2012 16:01:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TLfzM-0007Up-7a for qemu-devel@nongnu.org; Tue, 09 Oct 2012 16:01:17 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40697) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TLfzL-0007Tp-VV for qemu-devel@nongnu.org; Tue, 09 Oct 2012 16:01:12 -0400 Message-ID: <50748283.5020402@redhat.com> Date: Tue, 09 Oct 2012 16:01:07 -0400 From: Jeff Cody MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file Reply-To: jcody@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kashyap Chamarthy Cc: qemu-devel@nongnu.org On 10/09/2012 04:54 AM, Kashyap Chamarthy wrote: > Hi (Jeff?) > > I was testing blockcommit operations qemu-git, as of Oct-6th (which > has your blockcommit code pulled in). And also w/ libvirt-git which > has Eric's libvirt blockcommit patches applied. > > with the goal of : > > actual state: [base] <-- [snap-1] <-- [snap-2] <-- [snap3] <-- [active-layer] > > desired state: [base] <-- [active-layer] > > When I actually do the operation, this is what I see > ----------------------------------------------- > $ virsh blockcommit --domain raw-base vda --wait --base > /export/vmimgs2/raw-base.img --top > /var/lib/libvirt/images/snap3-b-raw-base.qcow2 --verbose > error: internal error unable to execute QEMU command 'block-commit': > Could not open > '/export/vmimgs2/raw-base.img' > ----------------------------------------------- > On libvirt list, Eric indicated it could be a problem in qemu's > blockcommit code . > Do you know the command that libvirt is sending QEMU? If QEMU is sending and error response back to libvirt, it would be useful to know that as well. Also, are you using absolute filenames for the images? There are known issues right now with relative filenames with commit (and stream). I just grabbed the upstream code, built it and tried it out with raw, and it worked fine with a raw base, and qcow2 snapshots on top: { "execute": "block-commit", "arguments": { "device": "virtio0", "base": "/home/Jeff.Cody/virt/images/test/f16-commit.raw", "top": "/home/Jeff.Cody/virt/images/test/f16-commit-2-rawbase.img" } } {"return": {}} {"timestamp": {"seconds": 1349811474, "microseconds": 937437}, "event": "BLOCK_JOB_COMPLETED", "data": {"device": "virtio0", "len": 6442450944, "offset": 6442450944, "speed": 140122839052112, "type": "commit"}} This was for an image chain that was: raw <- qcow2 <- qcow2 <- qcow2 which became: raw <- qcow2 >>From qemu-img: # qemu-img info f16-commit.raw image: f16-commit.raw file format: raw virtual size: 6.0G (6442450944 bytes) disk size: 1.6G # qemu-img info f16-commit-3-rawbase.img image: f16-commit-3-rawbase.img file format: qcow2 virtual size: 6.0G (6442450944 bytes) disk size: 516K cluster_size: 65536 backing file: /home/Jeff.Cody/virt/images/test/f16-commit.raw (actual path: /home/Jeff.Cody/virt/images/test/f16-commit.raw) > > Although blockcommit to a qcow2 base file works just fine. > ----------------------------------------------- > [root moon libvirt]# virsh blockcommit --domain f17-base vda --wait --base > /export/vmimgs2/f17-base.qcow2 --top > /export/vmimgs2/snap3-f17-base.qcow2 --verbose > Block Commit: [100 %] > Commit complete > [root moon libvirt]# > ----------------------------------------------- > > More info on tests I ran, posted to libvirt list -- > https://www.redhat.com/archives/libvir-list/2012-October/msg00226.html > > Let me know if I can help you debug this further. > > /kashyap >