kleines HA Cluster

[crmspezi]

Hallo zusammen und ein gutes neues jahr euch allen!

Ich habe es selbst nicht probiert, deshalb die Frage hier.

Funktioniert ein Cluster aus 2 PVE mit lokalem Storage + qdevice, einer Storage Replication (z.B.) alle 2 min. und HA, also beim Ausfall automatisches Verschieben?

Dass dies mit Shared Storage funktioniert ist klar.

VG crmspezi

 

[UdoB]

Hallo,

mit lokalem ZFS funktioniert

• Replikation zwischen zwei (oder mehreren) Hosts. Wie lange diese jeweils tatsächlich dauern hängt von mehreren Faktoren wie der Menge der geänderterten Daten, der Geschwindigkeit der Netzwerkverbindung, den Platten und der jeweiligen generellen IO-Last ab
• wenn HA "zuschlägt" werden die VMs auf dem überlebenden Host neu gestartet - und verwenden dazu den neuesten Snapshot, der in der Replikation enthalten ist

Zwei Minuten "Taktrate" ist aus meiner persönlichen Sicht aber recht ambitioniert!


Viel Erfolg

 

[crmspezi]

Hört sich doch gut an, probiere ich gern. Danke sehr!

 

[aaron]

Hab ich persönlich so im Einsatz in einem kleinen 2-Node Cluster. Wichtige VMs wie z.B. der Mailserver werden jede Minute repliziert. Mit halbwegs flottem Storage und wenn die VMs nicht zu viel schreiben ist das im Regelbetrieb durchaus machbar. Wenn jetzt eine neue VM repliziert wird oder sich sonst was groß ändert, kann es zwischendurch natürlich auch mal ein bisschen dauern, bis wieder der übliche Rhythmus eingehalten werden kann.

 

[crmspezi]

Danke für die Rückmeldung Aaron!

 

[Dunuin]

Wie genau sieht es denn bei der Replikation aus wenn sich die "zfs send | zfs recv" Befehle der Replication überschneiden? Ist es dann bei PVE unproblematisch, wenn da bei einer minütlichen Replikation mal eine Replikation einige Minuten braucht, also die neue Replication triggert wärend die vorherige noch am laufen ist? Weil wenn ich das bei TrueNAS richtig in Erinnerung habe, dann sollte man dort den Intervall so wählen, dass es zu keinen Überschneidungen kommen kann.

 

[aaron]

IIRC läuft immer nur eine Replication gleichzeitig. Sprich, wenn du eine längere hast (neue VM z.B.) blockiert diese bis sie fertig ist.

 

[crmspezi]

Ich habe das Mal nun aufgesetzt und auf dem 1. Pve per pve-zsync noch eine andere Replikation auf einen Pve in einem anderen Cluster laufen. Nun habe ich einen 2. Pve und ein qdevice hinzugefügt und Storage Replikation zum 2. Pve eingerichtet. Läuft parallel mit pve-zsync.

Wenn ich nun Online eine VM verschieben will erhalte ich folgenden Fehler:

... online storage migration not possible if snapshot exists

Offline verschieben geht. Was mache ich falsch? Damit ist HA auch nicht lauffähig.

 

[aaron]

Hat die VM selbst snapshots?

Wie gut sich das mit anderen zfs send/recv Tools wie pve-zsync verträgt weiß ich gerade nicht und müsste ich mir anschauen.

 

[crmspezi]

Ich habe die pve-zsync entfernt (hat nichts gebracht - Job und Snapshots), die automatischen Snapshots per cv4pve Tool laufen natürlich jede Stunde, die Storage Replikation alle 5 min.

2018 hatte ich gelesen das Online-Migration im Cluster bei lokalem Storage nicht funktioniert, nur bei Shared Storage. 2020 habe ich im Forum gelesen das die Online-Migration nun funktioniert.

Wie gesagt, die Online Migration bricht mit dem Fehler "... online storage migration not possible if snapshot exists" ab. Das deutet darauf hin, das keine Snapshots existieren dürfen. Allerding macht die Replikation ja auch alle 5 min Snapshots.

Wie ist nun hier der Stand mit lokalem Storage / Online-Migration / vorhandenen Snapshots?

 

[aaron]

Sorry, ich hätte genauer sein sollen. Gibt es Snapshots der VM auf PVE Seite? Im Snapshot Panel... zu viele Orte wo das Wort Snapshot vorkommt

Die ZFS Snapshots selber sollten ziemlich egal sein, allerdings prüft die Live Migration auf vorhandene manuell erstellte Snapshots bei lokalem Storage.

 

[fabian]

online migration mit snapshots funktioniert mit ZFS (in kombination mit replication sogar besonders gut - hier muss dann ja nur mehr das delta uebertragen werden!). bitte poste mal die storage.cfg, die VM config und den migrations log..

 

[crmspezi]

Hallo Fabian, ein migrationslog im Dateisystem finde ich nicht, aus der Oberfläche schon.

dir: local
disable
path /var/lib/vz
content vztmpl,backup,iso
shared 0

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

zfspool: ZFSDATA
pool ZFSRAID
content rootdir,images
mountpoint /ZFSRAID
sparse 1

cifs: nasdisk2_ISOs
path /mnt/pve/nasdisk2_ISOs
server nasdisk2.firma.de
share ISOs
content iso
prune-backups keep-all=1
username backup

cifs: nasdisk2_pve_configs
path /mnt/pve/nasdisk2_pve_configs
server nasdisk2.firma.de
share home
content backup
prune-backups keep-all=1
username backup

pbs: pbs02
datastore pbs_pve-c2-01
server pbs02.firma.de
content backup
fingerprint 1d:25:33:f0:db:70:45:c9:66:fa:8b:94:e7:af:b5:8d:f8:d5:21:f6:7b:ab:f2:8a:5e:e0:5d:27:5f:fe:6d:73
prune-backups keep-all=1
username root@pam

#######################################

boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220117062902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220109122901]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220108122902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1641727741
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220110062902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220109122901
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1641792542
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220110122902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220110062902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1641814142
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220111062902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220110122902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1641878942
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220111122902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220111062902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1641900542
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220112062902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220111122902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1641965342
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220112122901]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220112062902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1641986941
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220113062902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220112122901
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1642051742
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220113122902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220113062902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1642073342
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220114062902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220113122902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1642138142
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220114122902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220114062902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1642159742
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220116062902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220114122902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1642310942
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220116122902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220116062902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1642332542
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

[autodaily220117062902]
#cv4pve-autosnap
boot: order=sata0;scsi0
cores: 2
cpu: qemu64,flags=+pdpe1gb;+aes
machine: q35
memory: 2048
name: firma-pfSense-104-ADSL
net0: virtio=46:73:11:8D:47:C3,bridge=vmbr0
numa: 1
onboot: 1
ostype: l26
parent: autodaily220116122902
sata0: none,media=cdrom
scsi0: ZFSDATA:vm-186-disk-0,discard=on,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=edf6eab5-7330-423f-9430-fcb57d76bc3a
snaptime: 1642397342
sockets: 1
vmgenid: d8d99d24-9254-4ef3-afaf-5b8cae9f9c1c

#######################################

task started by HA resource agent
2022-01-17 12:02:07 use dedicated network address for sending migration traffic (192.168.190.97)
2022-01-17 12:02:07 starting migration of VM 186 to node 'pve-c2-03' (192.168.190.97)
2022-01-17 12:02:07 found local, replicated disk 'ZFSDATA:vm-186-disk-0' (in current VM config)
2022-01-17 12:02:07 can't migrate local disk 'ZFSDATA:vm-186-disk-0': online storage migration not possible if snapshot exists
2022-01-17 12:02:07 ERROR: Problem found while scanning volumes - can't migrate VM - check log
2022-01-17 12:02:07 aborting phase 1 - cleanup resources
2022-01-17 12:02:07 ERROR: migration aborted (duration 00:00:00): Problem found while scanning volumes - can't migrate VM - check log
TASK ERROR: migration aborted

Nachtrag:
Das ist bei allen VM's (5) die gleiche Fehlermeldung (alle auf lokalem ZFSDATA)

 

[crmspezi]

Sorry, ich hätte genauer sein sollen. Gibt es Snapshots der VM auf PVE Seite? Im Snapshot Panel... zu viele Orte wo das Wort Snapshot vorkommt

Die ZFS Snapshots selber sollten ziemlich egal sein, allerdings prüft die Live Migration auf vorhandene manuell erstellte Snapshots bei lokalem Storage.

Hallo Aaron,
evtl. sind die cv4pve autosnapshots das Problem?

 

[fabian]

ja - weil das vollwertige PVE snapshots sind, und nicht nur ZFS snapshots (letztere werden mitgenommen). muesste genauer angeschaut werden ob die ausnahme nicht auch auf PVE snapshots welche ausschliesslich ZFS volumes referenzieren ausgedehnt werden koennte (sofern replication an ist, und alle referenzierten volumes repliziert werden)..

 

[crmspezi]

ja - weil das vollwertige PVE snapshots sind, und nicht nur ZFS snapshots (letztere werden mitgenommen). muesste genauer angeschaut werden ob die ausnahme nicht auch auf PVE snapshots welche ausschliesslich ZFS volumes referenzieren ausgedehnt werden koennte (sofern replication an ist, und alle referenzierten volumes repliziert werden)..

Das verstehe ich nicht, die cv4pve kann ich auch an der Console machen, diese sind über die API angestoßen worden. Snapshot ist Snapshot ohne Children. Den Begriff vollwertige pve-Snapshot, was ist das? Hier sind nur die VM's damit gesnapshotet. Siehe hier:


root@pve-c2-01:~# zfs list -t snapshot | grep vm-186
ZFSRAID/vm-186-disk-0@autodaily220110062902 5.04M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220110122902 4.04M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220111062902 2.46M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220111122902 2.60M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220112062902 2.72M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220112122901 2.69M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220113062902 2.55M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220113122902 2.57M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220114062902 2.44M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220114122902 2.44M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220115062902 2.62M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220115122902 2.56M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220116062902 3.78M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220116122902 2.43M - 1.42G -
ZFSRAID/vm-186-disk-0@rep_firma-pfSense-104-ADSL_2022-01-16_18:06:50 2.60M - 1.42G -
ZFSRAID/vm-186-disk-0@rep_firma-pfSense-104-ADSL_2022-01-17_06:10:15 1.75M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220117062902 1.74M - 1.42G -
ZFSRAID/vm-186-disk-0@autodaily220117122902 2.35M - 1.42G -
ZFSRAID/vm-186-disk-0@__replicate_186-0_1642429817__ 1.28M - 1.42G -

 

[fabian]

du kannst snapshots nur auf storage ebene machen (z.b. was im zuge einer replication passiert, oder auch von vielen 'zfs-auto-snapshot' tools), oder ueber die PVE API ('qm snapshot ..' / GUI / API) - bei letzterem wird ein eintrag in der VM config erstellt. derzeit laesst die migrationslogik zu, das ZFS snapshots mitgenommen werden wenn replication an ist, aber nicht wenn 'vollwertige' snapshots existieren.. theoretisch waere es moeglich diesen check und die dazugehoerige logik zu erweitern (dann muessten alle referenzierten volumes entweder repliziert sein, oder auf ZFS aber nicht in der aktuellen config referenziert werden -> die die repliziert sind werden dann weiterhin mit dem bestehenden mechanismus mit bitmap migriert, die anderen offline)

 

[crmspezi]

du kannst snapshots nur auf storage ebene machen (z.b. was im zuge einer replication passiert, oder auch von vielen 'zfs-auto-snapshot' tools), oder ueber die PVE API ('qm snapshot ..' / GUI / API) - bei letzterem wird ein eintrag in der VM config erstellt. derzeit laesst die migrationslogik zu, das ZFS snapshots mitgenommen werden wenn replication an ist, aber nicht wenn 'vollwertige' snapshots existieren.. theoretisch waere es moeglich diesen check und die dazugehoerige logik zu erweitern (dann muessten alle referenzierten volumes entweder repliziert sein, oder auf ZFS aber nicht in der aktuellen config referenziert werden -> die die repliziert sind werden dann weiterhin mit dem bestehenden mechanismus mit bitmap migriert, die anderen offline)

Ich verstehe es technisch nicht. Bitte erkläre es mir nochmals.

z.B. : ZFSRAID/vm-186-disk-0@autodaily220112062902 2.72M - 1.42G - wurde über die API erzeugt und ist sichtbar im PVE in der GUI.

Was ist hier der "vollwertige" Snapshot. Das ist doch das Gleiche als wenn ich manuell in der GUI einen erzeuge? Der Snapshot ist natürlich in der vm.conf sichtbar. Alle (!) Snapshots befinden sich an der Quelle und am Ziel, eben geprüft.

Soll ich nun alle Snapshots löschen vor der Migration damit dies funktioniert?

 

[crmspezi]

Auflösung:

1. ich habe alle Snapshots gelöscht (@autodaily) und alle manuellen per PVE
2. die Migration funktioniert nun mit aktivierter Storagereplikation und mit aktivierten pve-zsync auf einen anderen Server außerhalb des Clusters !!!
3. Erstelle ich nun einen manuellen Snapshot im PVE - Namens z.B. "OK" erhalte den o.g. Fehler bei der Migration.

Damit ist HA nicht mehr Online nutzbar ohne den pve-zsync Snapshot mit der "Aufbewahrungsrichtline - --maxsnap" für Aufbewahrungen lokal zu mißbrauchen. Ein wirklich böser Bug, denn mit pve-zsync als paraller Snapshot funktioniert ja, siehe hier:

root@pve-c2-01:~# zfs list -t snapshot | grep vm-186
ZFSRAID/vm-186-disk-0@rep_firma-pfSense-104-ADSL_2022-01-16_18:06:50 4.17M - 1.42G -
ZFSRAID/vm-186-disk-0@rep_firma-pfSense-104-ADSL_2022-01-17_06:10:15 2.68M - 1.42G -
ZFSRAID/vm-186-disk-0@__replicate_186-0_1642440921__ 1.24M - 1.42G -

Kommt nur ein anderer Snapshot dazu, ist es rum. Liegt es vielleicht daran das in der vm.conf kein Snapshot eingetragen werden darf wie bei Storage Replica oder pve-zsync?

 

[crmspezi]

Evtl. reicht wirklich in einer Config-Datei die Prüfung auf Snapshots in der vm.comf zu deaktivieren?