[SOLVED] VM wärend Backup oder Snapshot nicht zu gebrauchen

[waltar]

Ich wollte nur mal auf die nahezu unendlichen Dokus von Jim Salter mit seinen vielen praktischen und nachvollziehbaren Beispielen aufmerksam machen und Anregungen zum Nachdenken und weiter selbst probieren anregen.

 

[mabox]

Wenn du unter Datacenter > Storage > add einfach deinen ZFS Pool auswählst, einen Namen geben und am besten direkt Thin privisioning aktivieren.

Hab noch was , welche Block Size würdest Du mir empfehlen? 16k ist voreingestellt, könnte die nachträglich nochmal geändert werden? In der VM läuft eine Nextcloud mit allem drum und dran, also File Synchronisation, Bilder/Video Upload. Denke für kleine Files wäre eine kleine Block Size besser, für die größeren Files wie z.B. Video eher eine größere? Denke fast 16k wäre dann ein guter Kompromis?

 

[news]

Nö die Blocksize richtet sich nach den zu schreibenden min. Blöcken auf das Speicher-Medium.
Da gibt's für ZFS noch andere Parameter!

 

[mabox]

Kann ich den irgendwie prüfen wie aktuell meine Performance im Moment ist um irgendwie einen Anhaltspunkt zu bekommen wie gut oder schlecht sie ist?

Also ich weiß nicht, ich hab mal nur die root disk nach raw direkt in einen zfs pool migriert und mit dd read und write getestet.
Keine Ahnung ob ich richtig teste aber mir kommt es so vor als wäre es mit raw schlechter.

qcow:

dd if=/dev/zero of=/devsda bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,506055 s, 2,1 GB/s

dd if=/dev/sda of=/dev/null bs=1G count=1 iflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,662198 s, 1,6 GB/s

raw:

dd if=/dev/zero of=/devsda bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,515611 s, 2,1 GB/s


dd if=/dev/sda of=/dev/null bs=1G count=1 iflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,475817 s, 2,3 GB/s

Die Zahlen beim qcow2 schwanken aber auch, manchmal schlechter wie bei raw aber halt auch hin und wieder besser. Die von raw sind meistens fast identisch.
Ich will ganz sicher nicht das letzte Bit rauskitzeln aber mich jetzt auch nicht verschlechtern. Vom Gefühl und Logik denke ich aber das raw schon die besser Wahl wäre.


EDIT:
Meine EFI Disk lässt sich nicht in den zfs pool migrieren.

create full clone of drive efidisk0 (svm:101/vm-101-disk-0.qcow2)
drive mirror is starting for drive-efidisk0
drive-efidisk0: Cancelling block job
drive-efidisk0: Done.
TASK ERROR: storage migration failed: block job (mirror) error: drive-efidisk0: Source and target image have different sizes (io-status: ok)

Muss ich den pool wahrscheinlich nochmal neu anlegen mit einer anderen Block size?

EDIT:
Ich bekomme die EFI Disk nicht migriert.
Die Disk hat diese Parameter:
svm:101/vm-101-disk-0.qcow2.efitype=4m,pre-enrolled-keys=1,size=528K

Auf den ZFS Pool hab ich mittlerweile 1M eingestellt und dennoch erhalte ich diesen Fehler:

create full clone of drive efidisk0 (svm:101/vm-101-disk-6.raw)
TASK ERROR: storage migration failed: zfs error: cannot create 'spool/vm-101-disk-0': 'volblocksize' must be power of 2 from 512B to 16M

Jemand eine Idee?

 

[Falk R.]

Also ich weiß nicht, ich hab mal nur die root disk nach raw direkt in einen zfs pool migriert und mit dd read und write getestet.
Keine Ahnung ob ich richtig teste aber mir kommt es so vor als wäre es mit raw schlechter.

qcow:

dd if=/dev/zero of=/devsda bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,506055 s, 2,1 GB/s

dd if=/dev/sda of=/dev/null bs=1G count=1 iflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,662198 s, 1,6 GB/s

raw:

dd if=/dev/zero of=/devsda bs=1G count=1 oflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,515611 s, 2,1 GB/s


dd if=/dev/sda of=/dev/null bs=1G count=1 iflag=direct
1+0 records in
1+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 0,475817 s, 2,3 GB/s

Also ich sehe da bei raw deutlich bessere Werte. 1,6GB/s zu 2,3GB/s.

Die Zahlen beim qcow2 schwanken aber auch, manchmal schlechter wie bei raw aber halt auch hin und wieder besser. Die von raw sind meistens fast identisch.
Ich will ganz sicher nicht das letzte Bit rauskitzeln aber mich jetzt auch nicht verschlechtern. Vom Gefühl und Logik denke ich aber das raw schon die besser Wahl wäre.


EDIT:
Meine EFI Disk lässt sich nicht in den zfs pool migrieren.

create full clone of drive efidisk0 (svm:101/vm-101-disk-0.qcow2)
drive mirror is starting for drive-efidisk0
drive-efidisk0: Cancelling block job
drive-efidisk0: Done.
TASK ERROR: storage migration failed: block job (mirror) error: drive-efidisk0: Source and target image have different sizes (io-status: ok)

Muss ich den pool wahrscheinlich nochmal neu anlegen mit einer anderen Block size?

Zum EFI Disk migrieren muss eine VM immer ausgeschaltet sein.

EDIT:
Ich bekomme die EFI Disk nicht migriert.
Die Disk hat diese Parameter:
svm:101/vm-101-disk-0.qcow2.efitype=4m,pre-enrolled-keys=1,size=528K

Auf den ZFS Pool hab ich mittlerweile 1M eingestellt und dennoch erhalte ich diesen Fehler:

create full clone of drive efidisk0 (svm:101/vm-101-disk-6.raw)
TASK ERROR: storage migration failed: zfs error: cannot create 'spool/vm-101-disk-0': 'volblocksize' must be power of 2 from 512B to 16M

Jemand eine Idee?

 

[mabox]

Hallo @Falk R.
die Werte die Du genannt hast gehören eigentlich zu qcow2.
Wegen der EFI Migration:
Ist es dann egal welche Block size ich im ZFS Pool eingestellt habe? Die war auf 16k bisher, jetzt grad hab ich sie auf 1M.
Vielleicht lass ich sie auf 1M oder was denkst Du wäre ein Kompromiss für kleine und große Daten? In der VM läuft wie erwähnt eine Nextcloud.

 

[Falk R.]

Hallo @Falk R.
die Werte die Du genannt hast gehören eigentlich zu qcow2.

Dann hast du es falsch beschriftet. Das nur Write schneller ist und read identisch, bestätigt meine Vermutung, dass qcow nur wegen dem Cache schneller ist. Vermutlich bricht das aber deutlich ein wenn du ganz große Mengen schreibst.

Wegen der EFI Migration:
Ist es dann egal welche Block size ich im ZFS Pool eingestellt habe? Die war auf 16k bisher, jetzt grad hab ich sie auf 1M.
Vielleicht lass ich sie auf 1M oder was denkst Du wäre ein Kompromiss für kleine und große Daten? In der VM läuft wie erwähnt eine Nextcloud.

Ich persönlich würde nicht mit so großen Blocksizes arbeiten, das gibt eine Menge Overhead. Kommt aber immer auf deine Daten an, wie die aussehen, weißt nur du.

 

[mabox]

Wenn meine EFI anscheinend 528K hat muss ich dann den zfs pool mit mind. dieser Größe anlegen?
svm:101/vm-101-disk-0.qcow2.efitype=4m,pre-enrolled-keys=1,size=528K
Oder egal?
Daten sind halt Fotos/Videos, Kalender, Kontatke usw. die in die Nextcloud geladen werden oder gesynct.
Nachträglich kann ich die Block Size noch ändern? Ab wann sind es für Dich "große" Blockgrößen?

EDIT:
Ok ich bin fetig, habe jetzt auf ZFS Pool mit raw disks umgebaut. Gefühlt ist es tatsächlich etwas schneller, z.B. bei Bilder oder Videos über die Galerie meine ich flutscht es etwas schneller. War aber auch vorher schon sehr gut.
Was auf jedenfall schneller ist sind Snapshots erstellen Das geht jetzt in einer Sekunde, vorher brauchte es ein paar Sekunden.....
Jetzt mach ich mir mal noch Gedanken wie sinnvoll oder störend mein LVM Stripping Konstrukt ist.
Jedenfalls vielen Dank für Euere Hilfe bei dem Thema!