qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v1 0/6]: block: Add I/O status support


From: Kevin Wolf
Subject: Re: [Qemu-devel] [PATCH v1 0/6]: block: Add I/O status support
Date: Mon, 19 Sep 2011 16:29:12 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0.2) Gecko/20110906 Thunderbird/6.0.2

Am 19.09.2011 16:09, schrieb Luiz Capitulino:
> On Mon, 19 Sep 2011 15:40:06 +0200
> Kevin Wolf <address@hidden> wrote:
> 
>> Am 01.09.2011 20:37, schrieb Luiz Capitulino:
>>> This series adds support to the block layer to keep track of devices'
>>> I/O status. That information is also made available in QMP and HMP.
>>>
>>> The goal here is to allow management applications that miss the
>>> BLOCK_IO_ERROR event to able to query the VM to determine if any device has
>>> caused the VM to stop and which device caused it.
>>>
>>> Please, note that this series depends on the following series:
>>>
>>>  o [PATCH v3 0/8]: Introduce the RunState type
>>>  o http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg00118.html
>>>
>>> And to be able to properly test it you'll also need:
>>>
>>>  o [PATCH 0/3] qcow2/coroutine fixes
>>>  o http://lists.gnu.org/archive/html/qemu-devel/2011-09/msg00074.html
>>>
>>> Here's an HMP example:
>>>
>>>   (qemu) info status 
>>>   VM status: paused (io-error)
>>>   (qemu) info block
>>>   ide0-hd0: removable=0 io-status=ok file=disks/test2.img ro=0 drv=qcow2 
>>> encrypted=0
>>>   ide0-hd1: removable=0 io-status=nospace file=/dev/vg_doriath/kvmtest ro=0 
>>> drv=qcow2 encrypted=0
>>>   ide1-cd0: removable=1 locked=0 io-status=ok [not inserted]
>>>   floppy0: removable=1 locked=0 [not inserted]
>>>   sd0: removable=1 locked=0 [not inserted]
>>>
>>> The "info status" command shows that the VM is stopped due to an I/O error.
>>> By issuing "info block" it's possible to determine that the 'ide0-hd1' 
>>> device
>>> caused the error, which turns out to be due to no space.
>>
>> Looks like I didn't reply here yet?
> 
> No, you didn't.
> 
>> I still don't quite like that the devices are involved, but their part
>> is minimal and it makes the implementation much easier, so for me that's
>> acceptable.
> 
> Suggestions on better ways of implementing this are welcome! :)

I don't have one. :-)

Surely it would be possible to do everything in block.c, but I see that
this would make things much more complicated (would need to get an AIO
callback added to the chain that can save the error code). It's not
worth the trouble.

Kevin



reply via email to

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