During preparation for rollback, there already is a VM cleanup. The rollback operation temporarily drops the file lock for the configuration while doing rollback of the volumes on the storage layer. If a shutdown operation or more precisely, the cleanup thereafter happens concurrently, it can get the file lock and do the cleanup (a second time) while rollback is running. If a badly timed deactivate for the volume happens, this can cause issues as reported in the community forum [0] and confirmed locally (but only managed to reproduce with 'saferemove').
[0]: https://forum.proxmox.com/threads/174875/post-815273 Signed-off-by: Fiona Ebner <[email protected]> --- src/PVE/CLI/qm.pm | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/PVE/CLI/qm.pm b/src/PVE/CLI/qm.pm index bfce860f..60fe318e 100755 --- a/src/PVE/CLI/qm.pm +++ b/src/PVE/CLI/qm.pm @@ -1111,6 +1111,12 @@ __PACKAGE__->register_method({ my $pid = PVE::QemuServer::check_running($vmid); die "vm still running\n" if $pid; + # Rollback already does cleanup when preparing and afterwards temporarily drops the + # lock on the configuration file to rollback the volumes. Deactivating volumes here + # again while that is happening would be problematic. + die "skipping cleanup - 'rollback' lock is present\n" + if $conf->{lock} && $conf->{lock} eq 'rollback'; + if (!$clean) { # we have to cleanup the tap devices after a crash -- 2.47.3 _______________________________________________ pve-devel mailing list [email protected] https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
