The 'quit' QMP command itself is fast, since it only records the shutdown request and notifies the main loop, but getting the response can take a while. The reason is that qmp_dispatch() yields and must be woken after executing the command and at that stage, QEMU is already busy with teardown too.
In practice, users can run into the default timeout of 5 seconds when doing bulk suspend. The 'quit' QMP command is only used as part of (potentially) longer-running operations already: - VM hibernation - VM stop - QSD quit: - after enrolling EFI disk certs - terminating instance for TPM Signed-off-by: Fiona Ebner <[email protected]> --- src/PVE/QMPClient.pm | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/PVE/QMPClient.pm b/src/PVE/QMPClient.pm index 7610121a..a43e661b 100644 --- a/src/PVE/QMPClient.pm +++ b/src/PVE/QMPClient.pm @@ -156,6 +156,12 @@ sub cmd { || $cmd->{execute} eq 'blockdev-snapshot-internal-sync' ) { $timeout = 60 * 60; # 1 hour + } elsif ($cmd->{execute} eq 'quit') { + # The 'quit' QMP command itself is fast, since it only records the shutdown request and + # notifies the main loop, but getting the response can take a while. The reason is that + # qmp_dispatch() yields and must be woken after executing the command and at that stage, + # QEMU is already busy with teardown too. + $timeout = 60; } else { # NOTE: if you came here as user and want to change this, try using IO-Threads first # which move out quite some processing of the main thread, leaving more time for QMP -- 2.47.3
