From: Eric Blake <eblake@redhat.com>
To: Hitoshi Mitake <mitake.hitoshi@lab.ntt.co.jp>, qemu-devel@nongnu.org
Cc: Kevin Wolf <kwolf@redhat.com>,
mitake.hitoshi@gmail.com, Stefan Hajnoczi <stefanha@redhat.com>
Subject: Re: [Qemu-devel] [PATCH RFC] blkdebug: make the fault injection functionality callable from QMP
Date: Wed, 13 Aug 2014 08:20:53 -0600 [thread overview]
Message-ID: <53EB7445.4050300@redhat.com> (raw)
In-Reply-To: <1407905321-10219-1-git-send-email-mitake.hitoshi@lab.ntt.co.jp>
[-- Attachment #1: Type: text/plain, Size: 3825 bytes --]
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.
> 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.
> +{ '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.
> +##
> +{ '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/
> +##
> +{ '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).
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 539 bytes --]
next prev parent reply other threads:[~2014-08-13 14:21 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 [this message]
2014-08-14 7:10 ` Hitoshi Mitake
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=53EB7445.4050300@redhat.com \
--to=eblake@redhat.com \
--cc=kwolf@redhat.com \
--cc=mitake.hitoshi@gmail.com \
--cc=mitake.hitoshi@lab.ntt.co.jp \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.