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 <address@hidden> wrote:
> On Wed, Oct 10, 2012 at 1:31 AM, Jeff Cody <address@hidden> 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:
> #---------------------------------------------------------------------------------------#
> address@hidden 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
> address@hidden 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
> address@hidden 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
> address@hidden 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.

address@hidden ~]# 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


address@hidden ~]# 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
address@hidden ~]#


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