From: Zachary Amsden <zamsden@redhat.com>
To: Avi Kivity <avi@redhat.com>
Cc: libvir-list@redhat.com, Anthony Liguori <aliguori@us.ibm.com>,
Jan Kiszka <jan.kiszka@web.de>,
qemu-devel@nongnu.org, Hollis Blanchard <hollisb@us.ibm.com>
Subject: Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
Date: Sat, 11 Apr 2009 22:23:51 -1000 [thread overview]
Message-ID: <49E1A517.50105@redhat.com> (raw)
In-Reply-To: <49E124BB.1010604@redhat.com>
Zachary Amsden wrote:
> | 24H 100M 82V >
> You pierce the beastly fido's heart, you heartbreaker you...
> The beastly fido is dead!
> You receive 8 experience points.
> Your blood freezes as you hear the beastly fido's death cry.
>
> | 24H 100M 82V >
> The green gelatinous blob has arrived.
> The janitor picks up some trash.
You know, as silly as this little exercise is, it actually has some
interesting points. MUDs present a prompt showing the current status of
the player; hit points, mana, and V (movement points) are the default
display here, but typically you can customize the prompt to include many
variables and syntax to make it easy for you to parse... and simply
sending a NULL cmd (CR/LF) gets you a status update whenever you want.
Now, that's sort of the same thing a virtualization management tool
might want to monitor in the event of out-of-band asynchronous events -
number of online CPUs, RAM, and VM power status. Add command tagging so
you can associate responses to specific commands, and you've got a very
powerful monitor in a single I/O channel.
Personally, I think relying on asynchronous events to provide reliable
status is a bad idea. Management connections can and will get
disconnected, buffers will get filled and event notifications will be
dropped. Having a status line that is pollable by the client allows
easy access to all this information whenever it is needed.. such as an
error condition. Trying to stop an already stopped VM might confuse a
management program when it fails, and leaving the online status
indeterminate isn't a good thing to present to the user, but if a status
line is available, it is very convenient, easy to use, and never loses
information.
And it's really useful when your cleric's job is to hit enter to get
leader status as quickly as possible so they can recall the berzerker
who is buffing the mob before HP run out and they end up dead. Losing
XP from dying sucks, it takes days to get that back.
Zach
next prev parent reply other threads:[~2009-04-12 8:25 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-08 18:34 [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) Anthony Liguori
2009-04-08 18:34 ` [Qemu-devel] [PATCH 2/6] Introduce monitor 'wait' command (v2) Anthony Liguori
2009-04-08 18:34 ` [Qemu-devel] [PATCH 3/6] Introduce wait filtering (v2) Anthony Liguori
2009-04-08 18:35 ` [Qemu-devel] [PATCH 4/6] Document new events (v2) Anthony Liguori
2009-04-08 18:35 ` [Qemu-devel] [PATCH 5/6] Implement vm-state notifications (v2) Anthony Liguori
2009-04-08 18:35 ` [Qemu-devel] [PATCH 6/6] Implement vnc-event " Anthony Liguori
2009-04-08 18:43 ` [Qemu-devel] Re: [PATCH 2/6] Introduce monitor 'wait' command (v2) Anthony Liguori
2009-04-08 19:01 ` [Qemu-devel] " Blue Swirl
2009-04-08 19:02 ` Anthony Liguori
2009-04-09 11:01 ` Avi Kivity
2009-04-09 13:40 ` Anthony Liguori
2009-04-09 13:58 ` Avi Kivity
2009-04-09 14:19 ` Jan Kiszka
2009-04-09 8:19 ` [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) Avi Kivity
2009-04-09 13:28 ` Anthony Liguori
2009-04-09 13:40 ` Avi Kivity
2009-04-09 13:47 ` Anthony Liguori
2009-04-09 14:03 ` Avi Kivity
2009-04-09 14:13 ` Anthony Liguori
2009-04-09 14:28 ` Avi Kivity
2009-04-09 14:30 ` Anthony Liguori
2009-04-09 14:37 ` Avi Kivity
2009-04-09 14:57 ` Anthony Liguori
2009-04-09 15:11 ` Avi Kivity
2009-04-09 15:40 ` Anthony Liguori
2009-04-09 15:57 ` Avi Kivity
2009-04-09 16:09 ` Anthony Liguori
2009-04-09 16:30 ` Avi Kivity
2009-04-09 16:42 ` Anthony Liguori
2009-04-09 17:00 ` Avi Kivity
2009-04-09 17:40 ` Anthony Liguori
2009-04-11 16:25 ` Avi Kivity
2009-04-11 20:18 ` Anthony Liguori
2009-04-11 21:14 ` Avi Kivity
2009-04-12 18:42 ` Jamie Lokier
2009-04-14 8:30 ` [libvirt] " Daniel P. Berrange
2009-04-14 9:15 ` Avi Kivity
2009-04-14 9:17 ` Daniel P. Berrange
2009-04-14 9:29 ` Jan Kiszka
2009-04-14 9:36 ` Avi Kivity
2009-04-14 9:38 ` Avi Kivity
2009-04-14 18:21 ` Jamie Lokier
2009-04-14 18:19 ` Jamie Lokier
2009-04-16 9:03 ` Avi Kivity
2009-04-11 23:16 ` Zachary Amsden
2009-04-12 8:23 ` Zachary Amsden [this message]
2009-04-14 8:28 ` Gerd Hoffmann
2009-04-14 18:20 ` Jamie Lokier
2009-04-11 19:11 ` Avi Kivity
2009-04-11 21:47 ` Andreas Färber
2009-04-12 18:44 ` Jamie Lokier
2009-04-09 16:01 ` Jamie Lokier
2009-04-09 14:15 ` [libvirt] " Gerd Hoffmann
2009-04-09 14:19 ` Avi Kivity
2009-04-09 14:56 ` Jan Kiszka
2009-04-09 15:15 ` François Revol
2009-04-09 15:15 ` Avi Kivity
2009-04-09 15:49 ` Jan Kiszka
2009-04-09 16:01 ` Avi Kivity
2009-04-09 16:07 ` Jamie Lokier
2009-05-11 20:54 ` Hollis Blanchard
2009-05-11 21:51 ` Anthony Liguori
2009-05-12 8:48 ` Avi Kivity
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=49E1A517.50105@redhat.com \
--to=zamsden@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=avi@redhat.com \
--cc=hollisb@us.ibm.com \
--cc=jan.kiszka@web.de \
--cc=libvir-list@redhat.com \
--cc=qemu-devel@nongnu.org \
/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).