From: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
To: Eric Blake <eblake@redhat.com>
Cc: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>,
Kevin Wolf <kwolf@redhat.com>,
mitake.hitoshi@gmail.com, qemu-devel@nongnu.org,
Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC] blkdebug: make the fault injection functionality callable from QMP
Date: Thu, 14 Aug 2014 16:10:43 +0900 [thread overview]
Message-ID: <87d2c3sg0c.wl%mitake.hitoshi@lab.ntt.co.jp> (raw)
In-Reply-To: <53EB7445.4050300@redhat.com>
At Wed, 13 Aug 2014 08:20:53 -0600,
Eric Blake wrote:
>
> [1 <text/plain; UTF-8 (quoted-printable)>]
> On 08/12/2014 10:48 PM, Hitoshi Mitake wrote:
> > This patch makes the fault injection functionality of blkdebug
> > callable from QMP. Motivation of this change is for testing and
> > debugging distributed systems. Ordinal distributed systems must handle
> > hardware faults because of its reason for existence, but testing
> > whether the systems can hanle such faults and recover in a correct
> > manner is really hard.
> >
>
> >
> > {"execute": "set-block-fault-state", "arguments": {"id": "ide0-hd0",
> > "state": "error"}} # <- inject error to /dev/sda
> > {"return": {}}
> >
>
> Sounds interesting.
Hi Eric, thanks a lot for your review.
>
> > Now the guest OS on the VM finds the disk is broken.
> >
> > Of course, using QMP directly is painful for users (developers and
> > admins of distributed systems). I'm implementing user friendly
> > interface in vagrant-kvm [4] for blackbox testing. In addition, a
> > testing framework for injecting faults at critical timing (which
> > requires solid understanding of target systems) is in progress.
> >
> > [1] http://ucare.cs.uchicago.edu/pdf/socc13-limplock.pdf
> > [2] http://docs.openstack.org/developer/swift/howto_installmultinode.html
> > [3] http://www.amazon.com/dp/B00C93QFHI
> > [4] https://github.com/adrahon/vagrant-kvm
> >
> > Cc: Kevin Wolf <kwolf@redhat.com>
> > Cc: Stefan Hajnoczi <stefanha@redhat.com>
> > Signed-off-by: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>
> > ---
>
> > +++ b/qapi-schema.json
> > @@ -3481,3 +3481,42 @@
> > # Since: 2.1
> > ##
> > { 'command': 'rtc-reset-reinjection' }
> > +
> > +##
> > +# @BlockFaultState:
> > +#
> > +# Injected fault state for a block device.
> > +#
> > +# @none: no fault
> > +#
> > +# @error: visible error
> > +#
>
> Needs a Since: 2.2 line, as well as the ## trailing marker.
Thanks for pointing, I'll update it in v2.
>
> > +{ 'enum': 'BlockFaultState', 'data': [ 'none', 'error' ] }
> > +
> > +##
> > +# @query-block-fault-state:
> > +#
> > +# Return block fault state information for the given block device.
> > +#
> > +# @name: name of block device
> > +#
> > +# Returns: @BlockFaultState of a block device.
> > +#
> > +# Since: 1.6
>
> s/1.6/2.2/
>
> Personally, I think this command is overkill. Just enhance the existing
> query-block to output the fault state alongside everything else it
> already does. There's no need to add a new command that outputs a
> subset of the existing command.
I agree. The above command is needless as you say. I'll enhance
query-block in v2.
>
> > +##
> > +{ 'command': 'query-block-fault-state', 'data': { 'id': 'str' },
> > + 'returns': 'BlockFaultState' }
> > +##
> > +# @set-block-fault-state:
> > +#
> > +# Set fault state for the given block device.
> > +#
> > +# @name: the chardev's ID, must exist and not be in use
> > +# @state: fault state
> > +#
> > +# Returns: Nothing on success
> > +#
> > +# Since: 1.6
>
> s/1.6/2.2/
Thanks, I'll fix it in v2, too.
>
> > +##
> > +{ 'command': 'set-block-fault-state', 'data': {'id': 'str',
> > + 'state': 'BlockFaultState' }}
> > diff --git a/qmp-commands.hx b/qmp-commands.hx
> > index 4be4765..96ae7e2 100644
> > --- a/qmp-commands.hx
> > +++ b/qmp-commands.hx
> > @@ -3755,3 +3755,27 @@ Example:
> > <- { "return": {} }
> >
> > EQMP
> > + {
> > + .name = "query-block-fault-state",
> > + .args_type = "id:s",
> > + .mhandler.cmd_new = qmp_marshal_input_query_block_fault_state,
> > + },
> > +
> > +SQMP
> > +query-block-fault-state
> > +-----------------------
> > +
> > +Show block fault information.
> > +
> > +EQMP
> > + {
> > + .name = "set-block-fault-state",
> > + .args_type = "id:s,state:q",
> > + .mhandler.cmd_new = qmp_marshal_input_set_block_fault_state,
> > + },
> > +
> > +SQMP
> > +set-block-fault-state
> > +-----------------------
> > +
> > +Set block fault information.
> >
>
> It would be nice to include an example section for the new command(s)
> (well, I argue that only one new command is needed).
OK, I'll add an example in v2.
Thanks,
Hitoshi
next prev parent reply other threads:[~2014-08-14 7:10 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-08-13 4:48 [Qemu-devel] [PATCH RFC] blkdebug: make the fault injection functionality callable from QMP Hitoshi Mitake
2014-08-13 14:20 ` Eric Blake
2014-08-14 7:10 ` Hitoshi Mitake [this message]
2014-08-13 14:33 ` Stefan Hajnoczi
2014-08-14 7:13 ` Hitoshi Mitake
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87d2c3sg0c.wl%mitake.hitoshi@lab.ntt.co.jp \
--to=mitake.hitoshi@lab.ntt.co.jp \
--cc=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mitake.hitoshi@gmail.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).