Daniel P. Berrangé <berrange@redhat.com> writes:
The default monitor is usually a long lived object that will exist for the entire lifetime of the VM. A monitor can only service a single client at a time though, and so it might be desirable to hotplug additional monitors at runtime for specific tasks. If doing that, however, there is a need to remove the monitor when it is no longer needed.
A use case for hotplugging a monitor can involved a user wishing to
Typo: involve
spawn an adhoc script that uses a temporary monitor. The script can
ad hoc
ask the management application to hotplug a monitor and pass back a pre-opened FD using SCM_RIGHTS. In this case the lifetime of the script is not tied to the management application and thus it is desirable to have automatic cleanup when the script exits.
Allowing a client to run "object-del" against its own monitor adds complex edge cases, as it would be desirable to send the QMP response despite the monitor sending it being deleted. Doing "object-del" alone will also result in orphaning a character device backend instance, as there is no opportunity to run the companion "chardev-del" command.
A simpler way to ensure cleanup is to add the concept of auto-deleting monitor objects. Specifically when the "CHR_EVENT_CLOSED" event is emitted, the equivalent of "object-del" + "chardev-del" can be run internally. Since the transient client has already droppped its monitor connection, there is no synchronization to be concerned about with sending QMP replies. There is still some internal synchronization needed, however, between the character device event callback and the bottom-half that runs the delete. There is a chance that an incoming client connection may arise before the bottom-half runs, which has to be checked. Once the monitor object is deleted, the event callback is unregistered from the character device, eliminating any further races before the character device is fully deleted.
This is implemented via a new "close-action=none|delete" property on the 'monitor-qmp' object. This concept could be extended with further actions in future, for example:
* close-action=shutdown - graceful guest shutdown * close-action=terminate - immediate guest poweroff * close-action=stop - pause guest CPUs while the monitor is not connected to any client
This is left as an exercise for future interested contributors.
Tested-by: Peter Krempa <pkrempa@redhat.com> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com> Acked-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Happy to fix typos without a respin.