* [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file @ 2012-10-09 8:54 Kashyap Chamarthy 2012-10-09 20:01 ` Jeff Cody 0 siblings, 1 reply; 4+ messages in thread From: Kashyap Chamarthy @ 2012-10-09 8:54 UTC (permalink / raw) To: qemu-devel 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 . 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file 2012-10-09 8:54 [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file Kashyap Chamarthy @ 2012-10-09 20:01 ` Jeff Cody 2012-10-10 8:39 ` Kashyap Chamarthy 0 siblings, 1 reply; 4+ messages in thread From: Jeff Cody @ 2012-10-09 20:01 UTC (permalink / raw) To: Kashyap Chamarthy; +Cc: qemu-devel 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 > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file 2012-10-09 20:01 ` Jeff Cody @ 2012-10-10 8:39 ` Kashyap Chamarthy 2012-10-10 13:22 ` Kashyap Chamarthy 0 siblings, 1 reply; 4+ messages in thread From: Kashyap Chamarthy @ 2012-10-10 8:39 UTC (permalink / raw) To: jcody; +Cc: qemu-devel On Wed, Oct 10, 2012 at 1:31 AM, Jeff Cody <jcody@redhat.com> wrote: > 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. #---------------------------------------------------------------------------------------# 2012-10-10 08:00:59.821+0000: 11604: debug : qemuMonitorIOWrite:462 : QEMU_MONITOR_IO_WRITE: mon=0x7f1d68000cc0 buf={"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","speed":0,"top":"/var/lib/libvirt/images/snap3-b-raw-base.qcow2","base":"/export/vmimgs2/raw-base.img"},"id":"libvirt-6"} len=192 ret=192 errno=2 2012-10-10 08:00:59.823+0000: 11604: debug : qemuMonitorIOProcess:354 : QEMU_MONITOR_IO_PROCESS: mon=0x7f1d68000cc0 buf={"id": "libvirt-6", "error": {"class": "GenericError", "desc": "Could not open '/export/vmimgs2/raw-base.img'"}} len=114 2012-10-10 08:00:59.823+0000: 11604: debug : qemuMonitorJSONIOProcessLine:144 : Line [{"id": "libvirt-6", "error": {"class": "GenericError", "desc": "Could not open '/export/vmimgs2/raw-base.img'"}}] 2012-10-10 08:00:59.823+0000: 11604: debug : qemuMonitorJSONIOProcessLine:164 : QEMU_MONITOR_RECV_REPLY: mon=0x7f1d68000cc0 reply={"id": "libvirt-6", "error": {"class": "GenericError", "desc": "Could not open '/export/vmimgs2/raw-base.img'"}} 2012-10-10 08:00:59.823+0000: 11604: debug : qemuMonitorJSONIOProcess:215 : Total used 114 bytes out of 114 available in buffer 2012-10-10 08:00:59.823+0000: 11605: debug : qemuMonitorJSONCommandWithFd:262 : Receive command reply ret=0 rxObject=0xd5f8d0 2012-10-10 08:00:59.823+0000: 11605: debug : qemuMonitorJSONCheckError:336 : unable to execute QEMU command {"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","speed":0,"top":"/var/lib/libvirt/images/snap3-b-raw-base.qcow2","base":"/export/vmimgs2/raw-base.img"},"id":"libvirt-6"}: {"id":"libvirt-6","error":{"class":"GenericError","desc":"Could not open '/export/vmimgs2/raw-base.img'"}} 2012-10-10 08:00:59.823+0000: 11605: error : qemuMonitorJSONCheckError:347 : internal error unable to execute QEMU command 'block-commit': Could not open '/export/vmimgs2/raw-base.img' #---------------------------------------------------------------------------------------# I believe the above a permission error. I changed the owner ship of raw-base.img to qemu:qemu (from root:root) Then I try again blockcommit, I see this: (from libvirtd.log) #---------------------------------------------------------------------------------------# qemuMonitorIOWrite:462 : QEMU_MONITOR_IO_WRITE: mon=0x7f1d68000cc0 buf={"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","speed":0,"top":"/var/lib/libvirt/images/snap3-b-raw-base.qcow2","base":"/export/vmimgs2/raw-base.img"},"id":"libvirt-11"} len=193 ret=193 errno=11 qemuMonitorIOProcess:354 : QEMU_MONITOR_IO_PROCESS: mon=0x7f1d68000cc0 buf={"id": "libvirt-11", "error": {"class": "GenericError", "desc": "Top image file /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not found"}} len=141 : qemuMonitorJSONIOProcessLine:144 : Line [{"id": "libvirt-11", "error": {"class": "GenericError", "desc": "Top image file /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not found"}}] qemuMonitorJSONIOProcessLine:164 : QEMU_MONITOR_RECV_REPLY: mon=0x7f1d68000cc0 reply={"id": "libvirt-11", "error": {"class": "GenericError", "desc": "Top image file /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not found"}} qemuMonitorJSONIOProcess:215 : Total used 141 bytes out of 141 available in buffer qemuMonitorJSONCommandWithFd:262 : Receive command reply ret=0 rxObject=0xda26c0 qemuMonitorJSONCheckError:336 : unable to execute QEMU command {"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","speed":0,"top":"/var/lib/libvirt/images/snap3-b-raw-base.qcow2","base":"/export/vmimgs2/raw-base.img"},"id":"libvirt-11"}: {"id":"libvirt-11","error":{"class":"GenericError","desc":"Top image file /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not found"}} error : qemuMonitorJSONCheckError:347 : internal error unable to execute QEMU command 'block-commit': Top image file /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not found #---------------------------------------------------------------------------------------# But that file indeed exists, as can be seen below: #---------------------------------------------------------------------------------------# [kashyap@moon libvirt-k]$ file /var/lib/libvirt/images/snap3-b-raw-base.qcow2 /var/lib/libvirt/images/snap3-b-raw-base.qcow2: QEMU QCOW Image (v2), has backing file (path /var/lib/libvirt/images/snap2-b-raw-base.qcow2), 1073741824 bytes [kashyap@moon libvirt-k]$ ls -al /var/lib/libvirt/images/snap3-b-raw-base.qcow2 -rwxr--r--. 1 qemu qemu 1966080 Oct 8 10:17 /var/lib/libvirt/images/snap3-b-raw-base.qcow2 [kashyap@moon libvirt-k]$ ls -al /export/vmimgs2/raw-base.img -rw-r--r--. 1 qemu qemu 1073741824 Oct 10 13:40 /export/vmimgs2/raw-base.img [kashyap@moon libvirt-k]$ #---------------------------------------------------------------------------------------# > > Also, are you using absolute filenames for the images? There are known > issues right now with relative filenames with commit (and stream). I've been using only absolute file names (not relative, as I'm familiar w/ the errors). > > 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) Thank you. I'll have to try this again with today's QEMU git: (along with your newest patches for 'relative' paths maybe) > > > >> >> 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 >> > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file 2012-10-10 8:39 ` Kashyap Chamarthy @ 2012-10-10 13:22 ` Kashyap Chamarthy 0 siblings, 0 replies; 4+ messages in thread From: Kashyap Chamarthy @ 2012-10-10 13:22 UTC (permalink / raw) To: jcody; +Cc: qemu-devel On Wed, Oct 10, 2012 at 2:09 PM, Kashyap Chamarthy <kashyap.cv@gmail.com> wrote: > On Wed, Oct 10, 2012 at 1:31 AM, Jeff Cody <jcody@redhat.com> wrote: >> 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. > > #---------------------------------------------------------------------------------------# > 2012-10-10 08:00:59.821+0000: 11604: debug : qemuMonitorIOWrite:462 : > QEMU_MONITOR_IO_WRITE: mon=0x7f1d68000cc0 > buf={"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","speed":0,"top":"/var/lib/libvirt/images/snap3-b-raw-base.qcow2","base":"/export/vmimgs2/raw-base.img"},"id":"libvirt-6"} > len=192 ret=192 errno=2 > 2012-10-10 08:00:59.823+0000: 11604: debug : qemuMonitorIOProcess:354 > : QEMU_MONITOR_IO_PROCESS: mon=0x7f1d68000cc0 buf={"id": "libvirt-6", > "error": {"class": "GenericError", "desc": "Could not open > '/export/vmimgs2/raw-base.img'"}} > len=114 > 2012-10-10 08:00:59.823+0000: 11604: debug : > qemuMonitorJSONIOProcessLine:144 : Line [{"id": "libvirt-6", "error": > {"class": "GenericError", "desc": "Could not open > '/export/vmimgs2/raw-base.img'"}}] > 2012-10-10 08:00:59.823+0000: 11604: debug : > qemuMonitorJSONIOProcessLine:164 : QEMU_MONITOR_RECV_REPLY: > mon=0x7f1d68000cc0 reply={"id": "libvirt-6", "error": {"class": > "GenericError", "desc": "Could not open > '/export/vmimgs2/raw-base.img'"}} > 2012-10-10 08:00:59.823+0000: 11604: debug : > qemuMonitorJSONIOProcess:215 : Total used 114 bytes out of 114 > available in buffer > 2012-10-10 08:00:59.823+0000: 11605: debug : > qemuMonitorJSONCommandWithFd:262 : Receive command reply ret=0 > rxObject=0xd5f8d0 > 2012-10-10 08:00:59.823+0000: 11605: debug : > qemuMonitorJSONCheckError:336 : unable to execute QEMU command > {"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","speed":0,"top":"/var/lib/libvirt/images/snap3-b-raw-base.qcow2","base":"/export/vmimgs2/raw-base.img"},"id":"libvirt-6"}: > {"id":"libvirt-6","error":{"class":"GenericError","desc":"Could not > open '/export/vmimgs2/raw-base.img'"}} > 2012-10-10 08:00:59.823+0000: 11605: error : > qemuMonitorJSONCheckError:347 : internal error unable to execute QEMU > command 'block-commit': Could not open '/export/vmimgs2/raw-base.img' > #---------------------------------------------------------------------------------------# > I believe the above a permission error. I changed the owner ship of > raw-base.img to qemu:qemu (from root:root) > > Then I try again blockcommit, I see this: (from libvirtd.log) > #---------------------------------------------------------------------------------------# > qemuMonitorIOWrite:462 : QEMU_MONITOR_IO_WRITE: mon=0x7f1d68000cc0 > buf={"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","speed":0,"top":"/var/lib/libvirt/images/snap3-b-raw-base.qcow2","base":"/export/vmimgs2/raw-base.img"},"id":"libvirt-11"} > len=193 ret=193 errno=11 > > qemuMonitorIOProcess:354 : QEMU_MONITOR_IO_PROCESS: mon=0x7f1d68000cc0 > buf={"id": "libvirt-11", "error": {"class": "GenericError", "desc": > "Top image file /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not > found"}} > len=141 > > : qemuMonitorJSONIOProcessLine:144 : Line [{"id": "libvirt-11", > "error": {"class": "GenericError", "desc": "Top image file > /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not found"}}] > > qemuMonitorJSONIOProcessLine:164 : QEMU_MONITOR_RECV_REPLY: > mon=0x7f1d68000cc0 reply={"id": "libvirt-11", "error": {"class": > "GenericError", "desc": "Top image file > /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not found"}} > > qemuMonitorJSONIOProcess:215 : Total used 141 bytes out of 141 > available in buffer > > qemuMonitorJSONCommandWithFd:262 : Receive command reply ret=0 rxObject=0xda26c0 > > qemuMonitorJSONCheckError:336 : unable to execute QEMU command > {"execute":"block-commit","arguments":{"device":"drive-virtio-disk0","speed":0,"top":"/var/lib/libvirt/images/snap3-b-raw-base.qcow2","base":"/export/vmimgs2/raw-base.img"},"id":"libvirt-11"}: > {"id":"libvirt-11","error":{"class":"GenericError","desc":"Top image > file /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not found"}} > > error : qemuMonitorJSONCheckError:347 : internal error unable to > execute QEMU command 'block-commit': Top image file > /var/lib/libvirt/images/snap3-b-raw-base.qcow2 not found > #---------------------------------------------------------------------------------------# > > But that file indeed exists, as can be seen below: > #---------------------------------------------------------------------------------------# > [kashyap@moon libvirt-k]$ file /var/lib/libvirt/images/snap3-b-raw-base.qcow2 > /var/lib/libvirt/images/snap3-b-raw-base.qcow2: QEMU QCOW Image (v2), > has backing file (path > /var/lib/libvirt/images/snap2-b-raw-base.qcow2), 1073741824 bytes > [kashyap@moon libvirt-k]$ ls -al /var/lib/libvirt/images/snap3-b-raw-base.qcow2 > -rwxr--r--. 1 qemu qemu 1966080 Oct 8 10:17 > /var/lib/libvirt/images/snap3-b-raw-base.qcow2 > [kashyap@moon libvirt-k]$ ls -al /export/vmimgs2/raw-base.img > -rw-r--r--. 1 qemu qemu 1073741824 Oct 10 13:40 /export/vmimgs2/raw-base.img > [kashyap@moon libvirt-k]$ > #---------------------------------------------------------------------------------------# > >> >> Also, are you using absolute filenames for the images? There are known >> issues right now with relative filenames with commit (and stream). > > I've been using only absolute file names (not relative, as I'm > familiar w/ the errors). > >> >> 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) > > Thank you. I'll have to try this again with today's QEMU git: (along > with your newest patches for 'relative' paths maybe) um, weird, when I did a query on the block (w/ help from Eric), I see this. So it's already working ( but I could swear, the first time around it didn't return successful message). I need to reproduce this issue. [root@moon ~]# virsh qemu-monitor-command raw-base --hmp info block drive-virtio-disk0: removable=0 io-status=ok file=/var/lib/libvirt/images/snap4-b-raw-base.qcow2 backing_file=/export/vmimgs2/raw-base.img backing_file_depth=1 ro=0 drv=qcow2 encrypted=0 bps=0 bps_rd=0 bps_wr=0 iops=0 iops_rd=0 iops_wr=0 [root@moon ~]# qemu-img info /var/lib/libvirt/images/snap4-b-raw-base.qcow2 image: /var/lib/libvirt/images/snap4-b-raw-base.qcow2 file format: qcow2 virtual size: 1.0G (1073741824 bytes) disk size: 4.9M cluster_size: 65536 backing file: /export/vmimgs2/raw-base.img [root@moon ~]# >> >> >> >>> >>> 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 >>> >> ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2012-10-10 13:22 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-10-09 8:54 [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file Kashyap Chamarthy 2012-10-09 20:01 ` Jeff Cody 2012-10-10 8:39 ` Kashyap Chamarthy 2012-10-10 13:22 ` Kashyap Chamarthy
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).