[Qemu-devel] [RFC 0/3] QMP: extend BLOCK_IO_ERROR event

* [Qemu-devel] [RFC 0/3] QMP: extend BLOCK_IO_ERROR event
@ 2014-07-23 13:17 Luiz Capitulino
  2014-07-23 13:17 ` [Qemu-devel] [RFC 1/3] qapi: block-core.json: improve query-block doc Luiz Capitulino
                   ` (3 more replies)
  0 siblings, 4 replies; 15+ messages in thread
From: Luiz Capitulino @ 2014-07-23 13:17 UTC (permalink / raw)
  To: qemu-devel; +Cc: kwolf, pbonzini, armbru

Management software, such as OpenStack and RHEV's vdsm, wants to be able
to allocate VM disk space on demand. The basic use case is to start a VM
with a small disk and then the disk is enlarged when QEMU hits a ENOSPC
condition.

To this end, the management software has to be notified when QEMU
encounters ENOSPC. The most straightforward solution is to extend QMP's
BLOCK_IO_ERROR event with that information.

This series does exactly that. The approach taken is the simplest possible:
the BLOCK_IO_ERROR event is extended to contain a "nospace" key, which
will be true whenever the guest runs out of space *and* werror=stop|enospc.
Here's an example:

{ "event": "BLOCK_IO_ERROR",
    "data": { "device": "ide0-hd1",
	          "operation": "write",
			  "action": "stop",
			  "nospace": true },
    "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }

There are three important things to observe:

 1. query-block already supports querying the event by means of the
    "io-status" key. Actually, "nospace" and "io-status" keys share
    the same semantics. This is a big advantage of this approach, no
    further extension of query-block is needed

 2. The event could also contain an error message key for debugging,
    But if we add it to the event, should we add it to query-block too?

 3. I'm not extending BLOCK_JOB_ERROR. The reason is that it seems
    that BLOCK_IO_ERROR is also emitted on BLOCK_JOB_ERROR

Now, this series is an RFC because there's an alternative solution for
this problem: instead of extending the BLOCK_IO_ERROR event with no-space
indicator, we could have a stringfied errno. This way management apps
would also be able to distinguish among other errors.

For example, we could have a "error-details" dict containing a
"reason" and a "message" key:

{ "event": "BLOCK_IO_ERROR",
    "data": { "device": "ide0-hd1",
              "operation": "write",
              "action": "stop",
			  "error-details": { "reason": "eio", "message": "I/O error" },
    "timestamp": { "seconds": 1265044230, "microseconds": 450486 } }

And then query-block would have to be extended to contain the same
information.

IMO, this series implementation is good enough for the requirement we
currently have but I'm open to go complex if needed.

Luiz Capitulino (3):
  qapi: block-core.json: improve query-block doc
  QMP: rate limit BLOCK_IO_ERROR
  QMP: extend BLOCK_IO_ERROR event with no-space indicator

 block.c              | 22 ++++++++++++++--------
 monitor.c            |  1 +
 qapi/block-core.json |  8 +++++++-
 3 files changed, 22 insertions(+), 9 deletions(-)

-- 
1.9.3

^ permalink raw reply	[flat|nested] 15+ messages in thread