qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base i


From: Jeff Cody
Subject: Re: [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file
Date: Tue, 09 Oct 2012 16:01:07 -0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:15.0) Gecko/20120911 Thunderbird/15.0.1

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
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]