On 3/15/10, Kevin Wolf <kw...@redhat.com> wrote: > Am 15.03.2010 18:40, schrieb Blue Swirl: > > > On 3/15/10, Kevin Wolf <kw...@redhat.com> 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.