It's a commonly reported issue, most recently again in the enterprise
support, that taking or removing snapshots of large qcow2 files on
file-based network storages runs into a timeout. If the timeout is
hit, that just means additional manual steps to clean up afterwards
for users. The synchronous QMP command will still be blocking the main
thread of the QEMU instance until it has run to completion. Therefore,
a longer timeout does not really hurt here, while reducing the number
of times the aforementioned cleanup is necessary.
In the long term, using snapshot-as-volume-chain should be a good
alternative for such cases, once it's deemed production-ready.
Signed-off-by: Fiona Ebner <f.ebner at proxmox.com>
---
src/PVE/QMPClient.pm | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/src/PVE/QMPClient.pm b/src/PVE/QMPClient.pm
index e4f7a515..c3ed0e32 100644
--- a/src/PVE/QMPClient.pm
+++ b/src/PVE/QMPClient.pm
@@ -132,8 +132,6 @@ sub cmd {
$cmd->{execute} eq 'backup-cancel'
|| $cmd->{execute} eq 'blockdev-del'
|| $cmd->{execute} eq 'blockdev-mirror'
- || $cmd->{execute} eq 'blockdev-snapshot-delete-internal-sync'
- || $cmd->{execute} eq 'blockdev-snapshot-internal-sync'
|| $cmd->{execute} eq 'block-job-cancel'
|| $cmd->{execute} eq 'block-job-complete'
|| $cmd->{execute} eq 'drive-mirror'
@@ -146,6 +144,11 @@ sub cmd {
|| $cmd->{execute} eq 'savevm-start'
) {
$timeout = 10 * 60; # 10 mins
+ } elsif (
+ $cmd->{execute} eq 'blockdev-snapshot-delete-internal-sync'
+ || $cmd->{execute} eq 'blockdev-snapshot-internal-sync'
+ ) {
+ $timeout = 60 * 60; # 1 hour
} 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