Löschen von VM-Snapshots nach Speicher Erweiterung

plurgi95 · Monday at 11:35

Hallo,

mir ist aufgefallen Dass ich nach dem Hinzufügen von Speicherplatz bei einer VM den Erstellten Snapshot nicht mehr löschen kann wenn diese vor dem Hinzufügen von Speicherplatz schon bestand.

Hat hier jemand erfahrungen wie man die Snapshots ohne Datenverlust löschen kann?
Die VMs laufen nun schon einige tage und haben neue Daten geschrieben daher währe in diesem Fall ein Backup/Restore nicht möglich ohne Daten in der VM zu verlieren.

Dass Löschen sollte ohne Möglichst viel Downtime (Am besten garkeine) der VM Erledigt werden.

Aktuelle PVE Installation, Updates werden immer an einem Festen tag Installiert daher noch 0.0.2 Versionen hinterher.

Code:

proxmox-ve: 9.1.0 (running kernel: 6.17.9-1-pve)
pve-manager: 9.1.5 (running version: 9.1.5/80cf92a64bef6889)
proxmox-kernel-helper: 9.0.4
proxmox-kernel-6.17.9-1-pve-signed: 6.17.9-1
proxmox-kernel-6.17: 6.17.9-1
proxmox-kernel-6.17.4-2-pve-signed: 6.17.4-2
proxmox-kernel-6.8: 6.8.12-18
proxmox-kernel-6.8.12-18-pve-signed: 6.8.12-18
proxmox-kernel-6.8.12-9-pve-signed: 6.8.12-9
ceph-fuse: 19.2.3-pve2
corosync: 3.1.9-pve2
criu: 4.1.1-1
frr-pythontools: 10.4.1-1+pve1
ifupdown2: 3.3.0-1+pmx12
intel-microcode: 3.20251111.1~deb13u1
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-5
libproxmox-acme-perl: 1.7.0
libproxmox-backup-qemu0: 2.0.2
libproxmox-rs-perl: 0.4.1
libpve-access-control: 9.0.5
libpve-apiclient-perl: 3.4.2
libpve-cluster-api-perl: 9.0.7
libpve-cluster-perl: 9.0.7
libpve-common-perl: 9.1.7
libpve-guest-common-perl: 6.0.2
libpve-http-server-perl: 6.0.5
libpve-network-perl: 1.2.5
libpve-rs-perl: 0.11.4
libpve-storage-perl: 9.1.0
libspice-server1: 0.15.2-1+b1
lvm2: 2.03.31-2+pmx1
lxc-pve: 6.0.5-4
lxcfs: 6.0.4-pve1
novnc-pve: 1.6.0-3
proxmox-backup-client: 4.1.2-1
proxmox-backup-file-restore: 4.1.2-1
proxmox-backup-restore-image: 1.0.0
proxmox-firewall: 1.2.1
proxmox-kernel-helper: 9.0.4
proxmox-mail-forward: 1.0.2
proxmox-mini-journalreader: 1.6
proxmox-offline-mirror-helper: 0.7.3
proxmox-widget-toolkit: 5.1.5
pve-cluster: 9.0.7
pve-container: 6.1.1
pve-docs: 9.1.2
pve-edk2-firmware: 4.2025.05-2
pve-esxi-import-tools: 1.0.1
pve-firewall: 6.0.4
pve-firmware: 3.17-2
pve-ha-manager: 5.1.0
pve-i18n: 3.6.6
pve-qemu-kvm: 10.1.2-6
pve-xtermjs: 5.5.0-3
qemu-server: 9.1.4
smartmontools: 7.4-pve1
spiceterm: 3.4.1
swtpm: 0.8.0+pve3
vncterm: 1.9.1
zfsutils-linux: 2.4.0-pve1

Impact · Monday at 11:58

Da fehlen sehr viele Informationen. Was für Speicher wird benutzt? Wie wurde der Speicher der VM vergrößert? Was passiert bei Versuch des löschens?

plurgi95 · Monday at 12:45

Impact said:
Da fehlen sehr viele Informationen. Was für Speicher wird benutzt? WIe wurde der Speicher der VM vergrößert? Was apssiert bei Versuch des löschens?

Ah Sorry, Zu Schnell auf Absenden gedrückt.

Genutztzer Speicher: LVM Thick - Local im Host (6x 3,2TB SSD im HW-RAID5)

Erweitert über die GUI mit den Disk-Actions -> Größe Anpassen -> Größenänderung (GiB) 10 -> Resize Disk
Dann in Windows die Virtuelle Platte über den Diskmanager intern Vergrößert.

Die Task-Log:

Code:

delete qemu external snapshot
delete first snapshot Update
block-commit current to base:Update
commit-drive-scsi0: transferred 1.9 GiB of 46.0 GiB (4.09%) in 1s
commit-drive-scsi0: transferred 4.6 GiB of 46.0 GiB (9.94%) in 2s
commit-drive-scsi0: transferred 6.8 GiB of 46.0 GiB (14.69%) in 3s
commit-drive-scsi0: transferred 9.8 GiB of 46.0 GiB (21.20%) in 4s
commit-drive-scsi0: transferred 12.5 GiB of 46.0 GiB (27.08%) in 5s
commit-drive-scsi0: transferred 15.3 GiB of 46.0 GiB (33.25%) in 6s
commit-drive-scsi0: transferred 18.7 GiB of 46.0 GiB (40.64%) in 7s
commit-drive-scsi0: transferred 21.8 GiB of 46.0 GiB (47.35%) in 8s
commit-drive-scsi0: transferred 25.0 GiB of 46.0 GiB (54.39%) in 9s
commit-drive-scsi0: transferred 26.0 GiB of 46.0 GiB (56.47%) in 10s
commit-drive-scsi0: transferred 26.9 GiB of 46.0 GiB (58.43%) in 11s
commit-drive-scsi0: transferred 28.0 GiB of 46.0 GiB (60.78%) in 12s
commit-drive-scsi0: transferred 29.3 GiB of 46.0 GiB (63.69%) in 13s
commit-drive-scsi0: transferred 31.0 GiB of 46.0 GiB (67.38%) in 14s
commit-drive-scsi0: transferred 32.2 GiB of 46.0 GiB (70.04%) in 15s
commit-drive-scsi0: transferred 32.2 GiB of 46.0 GiB (70.04%) in 16s
commit-drive-scsi0: transferred 34.1 GiB of 46.0 GiB (74.19%) in 17s
commit-drive-scsi0: transferred 36.0 GiB of 46.0 GiB (78.28%) in 18s
commit-drive-scsi0: transferred 38.7 GiB of 46.0 GiB (84.17%) in 19s
commit-drive-scsi0: transferred 40.0 GiB of 46.0 GiB (86.87%) in 20s
commit-drive-scsi0: transferred 41.9 GiB of 46.0 GiB (91.18%) in 21s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 22s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 23s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 24s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 25s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 26s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 27s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 28s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 29s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 30s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 31s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 32s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 33s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 34s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 35s
commit-drive-scsi0: transferred 43.5 GiB of 46.0 GiB (94.52%) in 36s
commit-drive-scsi0: Cancelling block job
commit-drive-scsi0: Done.
TASK ERROR: Failed to complete block commit: block job (commit) error: commit-drive-scsi0: 'commit' has been cancelled

Impact · Monday at 12:49

Das löschen älterer Snapshots sollte keinen Einfluss auf den aktuellen Zustand des Gastes haben. Ich mach das ständig. Kannst du noch folgendes teilen?

Bash:

cat /etc/pve/storage.cfg
qm listsnapshot IDDERVMHIER
qm config IDDERVMHIER
lsblk -o+FSTYPE,LABEL,MODEL

Was für ein Task war das?

plurgi95 · Monday at 13:09

Impact said:
Was für ein Task war das?

Die VM (ID) - Lösche Snapshot Task

Hier nochmal die Gefragten infos.

Code:

 cat /etc/pve/storage.cfg
dir: local
        disable
        path /var/lib/vz
        content snippets
        shared 0

zfspool: local-zfs
        disable
        pool rpool/data
        content rootdir,images
        sparse 1

esxi: vm01
        server 192.168.190.3
        username root
        content import
        nodes pve03,pve02,pve01
        skip-cert-verification 1

esxi: vm04
        server 192.168.190.6
        username root
        content import
        nodes pve01,pve03,pve02
        skip-cert-verification 1

esxi: vm06
        server 192.168.190.8
        username root
        content import
        nodes pve03,pve02,pve01
        skip-cert-verification 1

nfs: ISO-NAS
        export /volume1/ISO
        path /mnt/pve/ISO-NAS
        server 192.168.190.14
        content iso,vztmpl
        nodes pve02,pve03,pve01
        prune-backups keep-all=1

lvm: data
        vgname data
        content images,rootdir
        nodes pve02,pve01
        saferemove 0
        shared 0
        snapshot-as-volume-chain 1

dir: storage
        path /mnt/pve/storage
        content rootdir,images
        is_mountpoint 1
        nodes pve03
        shared 0

Code:

qm listsnapshot 24110
`-> Update                2026-03-27 13:16:32     no-description
 `-> current                                            You are here!

Code:

qm config 24110
agent: 1,fstrim_cloned_disks=1
balloon: 0
bios: ovmf
boot: order=scsi0;scsi1
cores: 2
cpu: x86-64-v3
efidisk0: data:vm-24110-disk-0.qcow2,efitype=4m,format=qcow2,size=528K
hotplug: disk,network,usb,memory,cpu
machine: pc-q35-10.1,viommu=virtio
memory: 16384
meta: creation-qemu=10.1.2,ctime=1774450122
name: NNCRZ04-DC
net0: virtio=00:50:56:a0:f4:e2,bridge=clients,queues=4,tag=241
numa: 1
ostype: win10
parent: Simba-Update
scsi0: data:vm-24110-disk-1.qcow2,cache=writeback,discard=on,format=qcow2,iothread=1,size=135G,ssd=1
scsi1: data:vm-24110-disk-2.qcow2,cache=writeback,discard=on,format=qcow2,iothread=1,size=10G,ssd=1
scsi2: data:vm-24110-disk-3.qcow2,cache=writeback,discard=on,format=qcow2,iothread=1,size=240G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=4220b03f-c949-7bdc-d496-029ae8609b67
sockets: 2
tags: DC;Windows
vga: virtio
vmgenid: 79a193cb-f76f-4d62-8815-8e9a89f7cf8c

Code:

lsblk -o+FSTYPE,LABEL,MODEL
NAME                                               MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS FSTYPE      LABEL MODEL
sda                                                  8:0    0 372.6G  0 disk                               MO000400JWDKU
├─sda1                                               8:1    0  1007K  0 part
├─sda2                                               8:2    0     1G  0 part             vfat
└─sda3                                               8:3    0   371G  0 part             zfs_member  rpool
sdb                                                  8:16   0 372.6G  0 disk                               MO000400JWDKU
├─sdb1                                               8:17   0  1007K  0 part
├─sdb2                                               8:18   0     1G  0 part             vfat
└─sdb3                                               8:19   0   371G  0 part             zfs_member  rpool
sdc                                                  8:32   0  14.6T  0 disk             LVM2_member       LOGICAL VOLUME
├─data-vm--22220--disk--1.qcow2                    252:0    0    70G  0 lvm
├─data-vm--22220--disk--2.qcow2                    252:1    0    80G  0 lvm
├─data-vm--22220--disk--3.qcow2                    252:2    0    50G  0 lvm
├─data-vm--22220--disk--4.qcow2                    252:3    0    10G  0 lvm
├─data-vm--22220--disk--0.qcow2                    252:4    0     4M  0 lvm
├─data-vm--190111--disk--1.qcow2                   252:5    0   110G  0 lvm
├─data-vm--190111--disk--0.qcow2                   252:6    0     4M  0 lvm
├─data-snap_vm--24110--disk--1_Update.qcow2 252:7    0   125G  0 lvm
├─data-vm--22212--disk--1.qcow2                    252:8    0    70G  0 lvm
├─data-vm--24110--disk--1.qcow2                    252:9    0   135G  0 lvm
├─data-vm--25110--disk--1.qcow2                    252:10   0    50G  0 lvm
├─data-snap_vm--24110--disk--2_Update.qcow2 252:11   0    10G  0 lvm
├─data-vm--24110--disk--2.qcow2                    252:12   0    10G  0 lvm
├─data-snap_vm--23711--disk--1_EFI--Move.qcow2     252:13   0    70G  0 lvm
├─data-vm--23711--disk--1.qcow2                    252:14   0    70G  0 lvm
├─data-vm--22221--disk--3.qcow2                    252:15   0    90G  0 lvm
├─data-vm--22221--disk--4.qcow2                    252:16   0    20G  0 lvm
├─data-vm--22221--disk--2.qcow2                    252:17   0    50G  0 lvm
├─data-vm--22221--disk--1.qcow2                    252:18   0    50G  0 lvm
├─data-vm--22212--disk--0.qcow2                    252:19   0     4M  0 lvm
├─data-vm--22211--disk--1.qcow2                    252:20   0    85G  0 lvm
├─data-vm--22211--disk--0.qcow2                    252:21   0     4M  0 lvm
├─data-vm--22221--disk--0.qcow2                    252:22   0     4M  0 lvm
├─data-vm--22230--disk--0                          252:23   0    50G  0 lvm              ext4
├─data-vm--22223--disk--2.qcow2                    252:24   0    60G  0 lvm
├─data-vm--22223--disk--1.qcow2                    252:25   0    40G  0 lvm
├─data-vm--22223--disk--0.qcow2                    252:26   0     4M  0 lvm
├─data-snap_vm--23711--disk--0_EFI--Move.qcow2     252:27   0     4M  0 lvm
├─data-vm--23710--disk--0.qcow2                    252:28   0     4M  0 lvm
├─data-vm--23710--disk--1.qcow2                    252:29   0    70G  0 lvm
├─data-vm--23710--disk--2.qcow2                    252:30   0   100G  0 lvm
├─data-vm--23212--disk--0.qcow2                    252:31   0     4M  0 lvm
├─data-vm--25110--disk--2.qcow2                    252:32   0   255G  0 lvm
├─data-vm--25110--disk--0.qcow2                    252:33   0   200G  0 lvm
├─data-vm--25110--disk--4.qcow2                    252:34   0     4M  0 lvm
├─data-vm--23212--disk--1.qcow2                    252:35   0    85G  0 lvm
├─data-vm--23711--disk--0.qcow2                    252:36   0     4M  0 lvm
├─data-vm--25120--disk--1.qcow2                    252:40   0    80G  0 lvm
├─data-vm--25120--disk--2.qcow2                    252:41   0    50G  0 lvm
├─data-vm--25120--disk--3.qcow2                    252:42   0    20G  0 lvm
├─data-vm--25120--disk--4.qcow2                    252:43   0     4M  0 lvm
├─data-vm--25111--disk--1.qcow2                    252:44   0    80G  0 lvm
├─data-vm--25111--disk--3.qcow2                    252:45   0     4M  0 lvm
├─data-vm--22226--disk--1.qcow2                    252:46   0    70G  0 lvm
├─data-vm--22226--disk--0.qcow2                    252:47   0     4M  0 lvm
├─data-vm--22231--disk--0                          252:50   0    16G  0 lvm              ext4
├─data-vm--22232--disk--0                          252:52   0     4G  0 lvm              ext4
├─data-snap_vm--24110--disk--3_Update.qcow2 252:53   0   240G  0 lvm
├─data-vm--24110--disk--3.qcow2                    252:58   0   240G  0 lvm
├─data-snap_vm--24110--disk--0_Update.qcow2 252:59   0     4M  0 lvm
├─data-vm--24110--disk--0.qcow2                    252:60   0     4M  0 lvm
└─data-vm--24910--disk--0.qcow2                    252:62   0     8M  0 lvm
sdd                                                  8:48   1     0B  0 disk                               SD/MMC CRW

Impact · Monday at 14:46

Ah, nun macht thick LVM auch Sinn. Gab es einen bestimmten Grund, dass LVM-Thin nicht benutzt werden konnte?
Ich habe leider ziemlich 0 praktische Erfahrung mit snapshot-as-volume-chain und man sollte das Produktiv vermutlich eh nicht benutzen

Snapshots as Volume-Chain are a technology preview.

Bei mir sieht das übrigens so aus wenn ich versuche das zu reproduzieren. Vielleicht hilft das ja irgendwie

vm-102-disk-0.qcow2: deleting snapshot 'one' by commiting snapshot 'current'
running 'qemu-img commit /dev/test/vm-102-disk-0.qcow2'
Image committed.
delete vm-102-disk-0.qcow2
Logical volume "vm-102-disk-0.qcow2" successfully removed.
rename snap_vm-102-disk-0_one.qcow2 to vm-102-disk-0.qcow2
Renamed "snap_vm-102-disk-0_one.qcow2" to "vm-102-disk-0.qcow2" in volume group "test"
TASK OK

Ich nehme an qm delsnapshot 100 Update macht das gleiche Problem? Ich würde auch mal probieren ob sich etwas ändert wenn die VM ausgeschaltet ist.

plurgi95 · Monday at 14:57

Impact said:
Ah, nun macht thick LVM auch Sinn. Gab es einen bestimmten Grund, dass LVM-Thin nicht benutzt werden konnte?
Ich habe leider ziemlich 0 praktische Erfahrung mit snapshot-as-volume-chain und man sollte das Produktiv vermutlich eh nicht benutzen

Bei mir sieht das übrigens so aus wenn ich versuche das zu reproduzieren. Vielleicht hilft das ja irgendwie

Ich nehme an qm delsnapshot 100 Update macht das gleiche Problem? Ich würde auch mal probieren ob sich etwas ändert wenn die VM ausgeschaltet ist.

Der Grund für Thick-LVM war der dass wir den speicher nicht Überprovisionieren können.
Bei ThinLVM ist es ja schnell passiert wenn wir Migrieren dass der Speicher Überprovisioniert, Sonst gab es keine Günde.

Dass 'snapshot-as-volume-chain' Wollten wir auch eigentlich nicht Aktivieren aber es ist wohl im Eifer des Gefechts im Alltag unter Stress passiert dass jemand beim Einbinden eines neuen Hosts in den Cluster den Haken gesetzt hat..
Und Rückgängig machen geht ja auch nicht wenn VMs laufen auf dem Host daher versuchen wir grad mit einem Work-Around daran vorbei zu arbeiten.
Dazu müssen wir nur noch 2 Weitere Hosts ins RZ bringen die grad im Aufbau sind.

Ich teste dass mal sobald der kunde im Feierabend ist.

woma · 2026-04-17T08:08:11+0200

Mal eine ganz naive Denkweise...

Kann man nicht die Verbindung des aktuellen VM-Zustandes zur defekten Snapshot-Kette absichtlich zerstören, indem man die Disks der VM auf einen anderen Storage verschiebt? Das würde den aktuellen Zustand mitnehmen aber die Abhängigkeit von den Snapshots auf dem alten Storage beenden, richtig?

Danach Putzaktion auf dem alten Storage also die "unused disks" und deren Snapshots entfernen. Zur Not auf der Shell, wenn die GUI-Tools sich sträuben.
Nachdem alles alte Zeug von dieser VMID entsorgt wurde, könnte man die Disks wieder zurück schieben.

Oder übersehe ich da etwas?

plurgi95 · 2026-04-17T09:30:45+0200

woma said:
Mal eine ganz naive Denkweise...

Kann man nicht die Verbindung des aktuellen VM-Zustandes zur defekten Snapshot-Kette absichtlich zerstören, indem man die Disks der VM auf einen anderen Storage verschiebt? Das würde den aktuellen Zustand mitnehmen aber die Abhängigkeit von den Snapshots auf dem alten Storage beenden, richtig?

Danach Putzaktion auf dem alten Storage also die "unused disks" und deren Snapshots entfernen. Zur Not auf der Shell, wenn die GUI-Tools sich sträuben.
Nachdem alles alte Zeug von dieser VMID entsorgt wurde, könnte man die Disks wieder zurück schieben.

Oder übersehe ich da etwas?

Leider kann weder die VM noch die Disk verschoben werden sofern ein Snapshot vorhanden ist.
Daher würde dass nicht funktionieren.

und wir haben so oder so nur ein Storage pro Host.. bzw ein Cluster mit Dezentralem Storage

Search

Search

Löschen von VM-Snapshots nach Speicher Erweiterung

plurgi95

Member

Impact

Distinguished Member

plurgi95

Member

Impact

Distinguished Member

plurgi95

Member

Impact

Distinguished Member

plurgi95

Member

woma

New Member

plurgi95

Member

We value your privacy