[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' comm

From: Anthony Liguori
Subject: [Qemu-devel] Re: [libvirt] Re: [PATCH 2/3] Introduce monitor 'wait' command
Date: Wed, 08 Apr 2009 12:44:06 -0500
User-agent: Thunderbird (X11/20090320)

Gerd Hoffmann wrote:
On 04/08/09 16:33, Daniel P. Berrange wrote:
On Wed, Apr 08, 2009 at 09:16:43AM -0500, Anthony Liguori wrote:
The wait command will pause the monitor the command was issued in until a new event becomes available. Events are queued if there isn't a waiter present.
The wait command completes after a single event is available.

Today, we queue events indefinitely but in the future, I suspect we'll drop
events that are older than a certain amount of time to avoid infinitely
allocating memory for long running VMs.

To make use of the new notification mechanism, this patch introduces a
qemu_notify_event() API. This API takes three parameters: a class which is meant to classify the type of event being generated, a name which is meant to distinguish which event in the class that has been generated, and a details parameters which is meant to allow events to send arbitrary data with a given

Perhaps we should have the ability to turn on/off events, via a 'notify EVENT'
command, and a way turn off the prompt on the channel used for receiving

That would nicely solve the "queue events indefinitely" issue. By default no events are generated. Apps which want receive them (and thus receive them) can enable them as needed.

It doesn't. When an app enables events, we would start queuing them, but if it didn't consume them in a timely manner (or at all), we would start leaking memory badly.

We want to be robust even in the face of poorly written management apps/scripts so we need some expiration function too.

And then in the 2nd monitor channel, a single 'wait' command would turn
off the monitor prompt and make the channel dedicated for just events,
one per line

   (qemu) wait
   rtc-change UTC+0100
   vnc-client connect
   vnc-client disconnect
   vnc-client connect
   vnc-client disconnect

IMHO this is more useful than having "wait" just get one event. You'll need a dedicated monitor channel for events anyway, so with one-event-per-wait the management app would have to issue wait in a loop.

There two issues with this syntax. The first is that 'notify EVENT' logically acts on the global event set. That's not necessarily what you want. For instance, libvirt may attach to a monitor and issue a 'wait "vm-state vnc-events"' and I may have some wiz-bang app that wants to connect on another monitor, and issue a 'wait "watchdog-events"'. My super-deluxe app may sit watching for watchdog events to do some sort of fancy RAS stuff or something like that.

The 'notify EVENT' model makes this difficult unless you have notify act only on the current monitor session. Monitor "sessions" are ill-defined though b/c of things like tcp:// reconnects so I wouldn't want to do that.

The second issue is that there is no clear way to deliminate events other than a new line. If we wanted to send data along with events, we really want to be able to span multiple lines. Especially if we want that data to be in the same format as some of the existing monitor commands. You could get around this by introducing a new deliminator like '.' but everyone can already handle '(qemu)'.

That said, I can see a few advantages in the above model. Obviously, the ability to read a large chunk of output and then parse multiple events in a single round trip is a big positive. You could get that with my syntax by sending multiple wait commands at once but that's a bit hackish.

Also, I think where the above really shines is if you're a human user and you want to see all the events while debugging. You really don't want to keep typing wait in the monitor.

So as a compromise, I think we need to introduce a mode where we can do the above but I'd like to wait until after the first round of these go in. I'm thinking along the lines of 'wait N' where N can be -1 to signify an unlimited number of events or something like that.

BTW: "wait" is quite generic. Maybe we should name the commands notify-*, i.e. have

Good point, I like wait_event personally.


Anthony Liguori

  notify-enable $class
  notify-disable $class



Anthony Liguori

reply via email to

[Prev in Thread] Current Thread [Next in Thread]