[SOLVED] Replikation einer großen VM

[OsvaldoP]

Hallo an alle!

Ich sollte für eine VM mit knapp über 2TB ein Replikat auf den anderen Node des Clusters einrichten. Als Source und Destination dienen je ein ZFS Laufwerk im Mirrow mit 8TB von welchen 3 - 4TB bereits für VM benötigt werden.
Wenn ich das Replikat der VM einrichte reserviert sich die VM gute 4TB welches den Datastore volllaufen lässt.

* Die Disks der VM sind im RAW Format abgelegt.
* Compression am Datastore ist aktiv, Compressratio1.17x, Refcompressratio 1.00x

Gibt es eine Möglichkeit die Disks trotzdem zu replizieren? Könnte man eventuell eine Speicherreservierung der VM abdrehen? Wenn ja wie und welche Nachteile bringt dies mit sich?
Muss anschließend für das Replikat ein Snapshot der selben Größe am Source Datastore existieren oder könnte man diesen auf Änderungen minimieren?

Schon mal vielen Dank & sg
Roland

 

[fabian]

kannst du mal die storage.cfg, die VM config, "zfs list -t all -r -o space" und den genauen fehler posten?

 

[OsvaldoP]

Hallo Fabian!

Immer gerne, danke für deine Hilfe.
Hätte nun noch folgenden Link mit Infos von dir gefunden, Interessant wäre grad die 2TB Disk mit "thin" zu replizieren. Es handelt sich um ein Fileserver mit mehr als 90% starren Daten. Das Risiko wäre überschaubar für Replikat-Snapshots

https://forum.proxmox.com/threads/replication-error-out-of-space.103117/

storage.cfg

dir: local
        path /var/lib/vz
        content backup,iso,vztmpl
        prune-backups keep-last=1
        shared 0

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

zfspool: zfs01
        pool zfs01
        content images,rootdir
        mountpoint /zfs01
        nodes xxx
        sparse 0

zfspool: zfs02
        pool zfs02
        content images,rootdir
        mountpoint /zfs02
        sparse 0

pbs: pbs
        datastore zfs01
        server xxx
        content backup
        fingerprint xxx
        prune-backups keep-all=1
        username xxx

VM Config

agent: 1
boot: order=scsi0;ide2;net0
cores: 6
ide2: none,media=cdrom
machine: pc-i440fx-7.2
memory: 16000
meta: creation-qemu=7.2.0,ctime=1695894058
name: xxx
net0: virtio=00:50:56:9F:75:EA,bridge=vmbr0,firewall=1,tag=200
numa: 0
onboot: 1
ostype: win8
scsi0: zfs02:vm-200-disk-0,discard=on,iothread=1,size=80G
scsi1: zfs02:vm-200-disk-1,discard=on,iothread=1,size=2000G
scsihw: virtio-scsi-single
smbios1: uuid=ed376c5a-e73b-48a2-968b-106dd2b76f91
sockets: 1
startup: order=2
vmgenid: 4d67b1c1-2330-4c30-ae71-39691e48bd3d

zfs list -t all -r -o space

NAME                 AVAIL   USED  USEDSNAP  USEDDS  USEDREFRESERV  USEDCHILD
rpool                 175G  49.9G        0B    104K             0B      49.9G
rpool/ROOT            175G  49.9G        0B     96K             0B      49.9G
rpool/ROOT/pve-1      175G  49.9G        0B   49.9G             0B         0B
rpool/data            175G    96K        0B     96K             0B         0B
zfs01                4.94T   224G        0B    140K             0B       224G
zfs01/vm-103-disk-0  5.01T  89.2G        0B   16.4G          72.8G         0B
zfs01/vm-202-disk-0  4.96T   119G        0B   89.9G          29.0G         0B
zfs01/vm-202-disk-1  4.95T  14.9G        0B   17.1M          14.8G         0B
zfs02                3.91T  2.95T        0B    112K             0B      2.95T
zfs02/vm-101-disk-0  3.96T   155G        0B    101G          54.1G         0B
zfs02/vm-101-disk-1  3.91T  92.8G        0B   90.9G          1.93G         0B
zfs02/vm-101-disk-2  3.94T  72.2G        0B   38.2G          34.0G         0B
zfs02/vm-101-disk-3  4.08T   361G        0B    181G           180G         0B
zfs02/vm-200-disk-0  3.95T  82.5G        0B   43.4G          39.1G         0B
zfs02/vm-200-disk-1  4.36T  2.01T        0B   1.56T           463G         0B
zfs02/vm-201-disk-0  3.96T  82.5G        0B   32.6G          49.9G         0B
zfs02/vm-201-disk-1  3.98T   113G        0B   42.9G          70.5G         0B

 

[fabian]

yeah, the "issue" (it's not really an issue, just a tradeoff) is that your storage is not marked as sparse.

the upside to doing that is that you don't risk running out of space, since volumes on that storage are always fully reserved. the downside is that you cannot overcommit your storage, which means you will quickly run out of space when trying to do snapshots or allocate big volumes without actually using them.

in your specific case, creating a snapshot of "zfs02/vm-200-disk-1" requires reserving another 1.56T of space (+ overhead depending on your pool setup), since you could overwrite all of the current data, but the currently used data is also referenced by the snapshot.

 

[OsvaldoP]

Hy

normal verwenden wir kein Thin da wir in der Regel genug Speicher verbauen, weniger beim Erstellen /Ändern beachtet werden muss.
Wenn ich richtig verstehe dann ist die Lösung die Disk/VM in ein Speicher mit Thin zu legen, da nur Änderungen geschrieben werden und es ein Fileserver ist sollte der Speicherverbrauch der Disk gering bleiben.


Wäre es möglich ein weiteren Mountpoint am zfs02 zu erstellen und bei diesem Thin aktivieren?

zfs create -o mountpoint=/zfs02/thin zfs02/thin
Via Gui Thin-Prov aktivieren?

sg
Roland

 

[fabian]

bei ZFS kannst du das auch nachtraeglich aendern, der unterschied zwischen sparse/thin oder nicht ist nur ob eine (ref)reservation gesetzt ist - sh. dein zfs list output

 

[news]

Also ich würde eine NAS über einen Samba, Cifs auf einem LXC Debian 12 aufsetzen und so das ZFS Filesystem, evtl. über Quota, nutzen.
Anschließend die Daten überspielen, testen und anschließend die zfs02:vm-200-disk-1,size=2000G löschen.
So kannst du über jeden weiteren VM, LXC Backup Prozess diese Daten einfach löschen.

Klar kann man auch die VM herunter fahren, das ZFS-Drive vm-200-disk-1 lokal, auf dem Hostsystem, mounten und dann alles auf ein ZFS Volume kopieren.

 

[OsvaldoP]

hy

@fabian
wenn ich richtig raus höre, dann würdest du Thin auf den Pools aktivieren, auch wenn die eigentliche Disk dann nicht Thin ist ist es der Snapshot
Korrekt?

@news
Ich denke sowas könnte man auch wie folgt lösen:

Neuen mountpoint erstellen und ein Refquota erstellen, Vorteil nur der ThinStorage kann volllaufen und wenn dies passiert könnte man mit Quota rasch reagieren. Beim Erstellen neuer VM muss man dies halt beachten.

zfs create -o mountpoint=/zfs01/thin zfs01/thin
zfs set refquota=3000g /zfs01/thin

 

[fabian]

nein. bei ZFS ist thin oder nicht immer eine eigenschaft des einzelnen volumes/datasets. die option "sparse" in der storage.cfg kontrolliert nur ob bei neu angelegten volumes eine reservation gesetzt wird oder nicht. es gibt kein "snapshot nicht thin, volume schon" oder umgekehrt. es hat immer entweder das volume eine reservation oder eben nicht.

 

[OsvaldoP]

hmm

dann sollte ich vermutlich noch die refreservation auf non (also eine "thin disk" setzen

zfs set refreservation=none zfs02/vm-200-disk-1

Oder eben ein Thin Pool auf den selben Disks erstellen, Thin setzen und die Disk verschieben

zfs create -o mountpoint=/zfs01/thin zfs01/thin

Danke für dein Feedback
sg
Roland

 

[OsvaldoP]

Hallo

habe es nun mit einem "zfs set refreservation=none zfs02/vm-200-disk-1" lösen können.
Denke es ist für diesen Fall ausreichend

Danke für eure Unterstützung