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
event.
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.
--
Regards,
Anthony Liguori
--
Libvir-list mailing list
Libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list