[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)
aliguori at us.ibm.com
Thu Apr 9 13:47:08 UTC 2009
Avi Kivity wrote:
> hotplug disk
> -ENOSPC on disk
> It's true that events don't correlate directly to commands, but they
> do correlate to the state of the system and that is affected by commands.
events are time stamped. In non-human mode, I think command responses
should be time stamped too so that a management tool knows when the
event was generated and can correlate the system state to the particular
>>> Sure, we'll need to make sure notifications don't mix with command
>>> responses, and that all commands are acked (the (qemu) prompt serves
>>> that purpose now), but it seems to me do be a lot easier for the
>>> management end.
>> FWIW, you can have asynchronous completion of monitor commands. See
>> migration as an example. The (qemu) prompt is the ack that the
>> command is finished. You can only have one async command per monitor
>> session which is why you need multiple monitors.
> Migration has the -d switch to be truly async (not to wait). We need
> an async notifier to tell us migration has finished or failed.
Multiplexing multiple monitor sessions AFAICT is going to require a
non-human mode. But it's totally orthogonal to this patch set. You
could implement it today if you wanted.
>> If we had a non-human monitor mode, I think it would be fine to have
>> many monitors multiplexed over a single channel. The internal
>> monitor abstraction doesn't change.
> I don't understand why we need to multiplex many monitors over one
> channel. Let's keep one monitor, but with the ability to send
> notifications to the other end.
I don't understand how you think it would be implemented. Each command
is going to have a unique 'Monitor *' associated with it. How that ends
up being displayed to the user/management tool is irrelevant. Right
now, you can only have one 'Monitor *' active on a single "channel" at a
time. This is mostly a matter of output format. I don't see how we can
keep the monitor output consistent and compatible as it stands today and
still support multiple 'Monitor *'s active in a single channel.
More information about the libvir-list