[libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2)

[Anthony Liguori]

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