[Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file

[Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file

[Kashyap Chamarthy]

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

Re: [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file

[Jeff Cody]

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
> 

Re: [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file

[Kashyap Chamarthy]

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
>>
>

Re: [Qemu-devel] [with qemu-git] blockcommit to a ( 'raw' format) base image fails w/ unable to open the disk image file

[Kashyap Chamarthy]

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
>>>
>>