qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [6388] Stop VM on ENOSPC error.


From: Jan Kiszka
Subject: [Qemu-devel] Re: [6388] Stop VM on ENOSPC error.
Date: Wed, 25 Feb 2009 19:08:22 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Daniel P. Berrange wrote:
> On Wed, Feb 25, 2009 at 10:55:25AM -0600, Anthony Liguori wrote:
>> Anthony Liguori wrote:
>>> Revision: 6388
>>>          http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=6388
>>> Author:   aliguori
>>> Date:     2009-01-21 18:59:04 +0000 (Wed, 21 Jan 2009)
>>>
>>> Log Message:
>>> -----------
>>> Stop VM on ENOSPC error. (Gleb Natapov)
>>>
>>> This version of the patch adds new option "werror" to -drive flag.
>>> Possible values are:
>>>
>>> report    - report errors to a guest as IO errors
>>> ignore    - continue as if nothing happened
>>> stop      - stop VM on any error and retry last command on resume
>>> enospc    - stop vm on ENOSPC error and retry last command on resume
>>>            all other errors are reported to a guest.
>>>
>>> Default is "report" to maintain current behaviour.
>>>  
>> I recently got burnt by the default being "report".  I was doing an 
>> installation and ran out of disk space.  The guest did not do anything 
>> intelligible with the error reports and froze very hard (as you'd expect).
>>
>> Any objection to changing to default to enospc?
> 
> From a managment POV having QEMU change its state from running to
> paused behind our back is hard. You don't want to have to poll on
> 'info state' to see if the VM has paused, and QEMU provides us no
> async notification for this yet. So at this time, if QEMU auto-pauses
> we can't notice this change, and so again it'll just appear to the
> user as if it froze.
> 
> If we get async notifications available via the monitor, then making 
> the default enospc is very sensible.

Adding some "notify <event-list>" monitor command could be a way to
allow this without bothering every monitor user immediately (I'm
thinking of multiple, decoupled monitor terminals now). Well, this
particular error might be critical enough to let it pop up everywhere,
but I guess there could be less critical ones reported this way, too.

When implementing async notification, we just have to ensure that we
never push it between incomplete monitor output.

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux




reply via email to

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