qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [RFC][PATCH 0/7] blkdebug


From: Blue Swirl
Subject: Re: [Qemu-devel] [RFC][PATCH 0/7] blkdebug
Date: Mon, 15 Mar 2010 20:17:43 +0200

On 3/15/10, Kevin Wolf <address@hidden> wrote:
> Am 15.03.2010 18:40, schrieb Blue Swirl:
>
> > On 3/15/10, Kevin Wolf <address@hidden> wrote:
>  >> This patch series introduces a new block driver which acts as a protocol 
> and
>  >>  whose purpose it is to fail requests. To be more precise, I want it to 
> fail in
>  >>  configurable places, so that qemu-iotests can be extended with tests for 
> the
>  >>  error paths (for example for the case when something with metadata 
> writes goes
>  >>  wrong deep in qcow2).
>  >
>  > Nice. Do you think this could be extended (later) to inject errors
>  > also to guest from QEMU?
>
>
> Not sure what you mean by "from QEMU"? To allow injecting errors from
>  the monitor instead of based on rules? Sounds certainly doable.

I was thinking rule file, but monitor would be more flexible. Even
better: allow switching rule files from monitor :-).

>  Or do you just mean to make it work in qemu as opposed to qemu-io? This
>  really doesn't make a difference to the block layer. If it works in one,
>  it works in the other one, too.
>
>
>  > Then it would be nice to be able to inject
>  > errors when reading/writing to a specific guest block range and for
>  > other formats (raw etc.) too.
>
>
> Should work with all formats, it's implemented as a protocol (but it's
>  untested with everything but qcow2). So you basically stick it between
>  the format driver and the image file. The only thing that could be
>  needed for other formats is some additional events.
>
>  For the block range thing, this would need to implement some more
>  conditions instead of just checking the state, but in general this is
>  exactly the kind of things that I'd like to see supported eventually.
>
>  So I completely agree that this is the right direction for future
>  improvements, however I can't tell yet if (or when) I'll get to
>  implement it myself. My focus is really the qcow2 error paths for now.

Ok, it's enough to know at this stage that the architecture is
flexible for this.




reply via email to

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