Windows Server - Festplatte verkleinern fordert gesamten Host

A

Alvin2k8

Member
Feb 22, 2023
94
2
13
Guten Tag an alle,

wir haben ein komisches Phänomen:

Blech mit 2x AMD Epic 7282 , 512GB Ram und 8x SSDs als ZFS Storage im RaidZ2.
Maschine läuft gut, alles easy.

Wenn wir aber auf einer Virtuellen Windows Umgebung die Festplatte verkleinern, "stirbt" der Host fast ab.
CPU Auslastung nahezu 100% und IO Verzögerung teilweise nicht mehr messbar.

VMs sind mi iSCIS Single und IO Threat aktiv.

Ist das ein normales Verhalten?
 
Nur um das richtig zu verstehen, ihr verkleinert die Partition einer DIsk innerhalb von Windows?

Könntest du den Output folgender Befehle hier posten?
pveversion -v
qm config <VMID>
cat /etc/pve/storage.cfg
 
mira said:
Nur um das richtig zu verstehen, ihr verkleinert die Partition einer DIsk innerhalb von Windows?

Könntest du den Output folgender Befehle hier posten?
pveversion -v
qm config <VMID>
cat /etc/pve/storage.cfg
Click to expand...
proxmox-ve: 7.3-1 (running kernel: 5.15.85-1-pve)
pve-manager: 7.3-6 (running version: 7.3-6/723bb6ec)
pve-kernel-helper: 7.3-8
pve-kernel-5.15: 7.3-3
pve-kernel-5.15.102-1-pve: 5.15.102-1
pve-kernel-5.15.85-1-pve: 5.15.85-1
ceph-fuse: 14.2.21-1
corosync: 3.1.7-pve1
criu: 3.15-1+pve-1
glusterfs-client: 9.2-1
ifupdown: residual config
ifupdown2: 3.1.0-1+pmx3
ksm-control-daemon: 1.4-1
libjs-extjs: 7.0.0-1
libknet1: 1.24-pve2
libproxmox-acme-perl: 1.4.4
libproxmox-backup-qemu0: 1.3.1-1
libpve-access-control: 7.3-2
libpve-apiclient-perl: 3.2-1
libpve-common-perl: 7.3-2
libpve-guest-common-perl: 4.2-3
libpve-http-server-perl: 4.1-6
libpve-storage-perl: 7.3-2
libspice-server1: 0.14.3-2.1
lvm2: 2.03.11-2.1
lxc-pve: 5.0.2-2
lxcfs: 5.0.3-pve1
novnc-pve: 1.4.0-1
proxmox-backup-client: 2.3.3-1
proxmox-backup-file-restore: 2.3.3-1
proxmox-mail-forward: 0.1.1-1
proxmox-mini-journalreader: 1.3-1
proxmox-offline-mirror-helper: 0.5.1-1
proxmox-widget-toolkit: 3.5.5
pve-cluster: 7.3-2
pve-container: 4.4-2
pve-docs: 7.3-1
pve-edk2-firmware: 3.20221111-1
pve-firewall: 4.2-7
pve-firmware: 3.6-4
pve-ha-manager: 3.5.1
pve-i18n: 2.8-3
pve-qemu-kvm: 7.2.0-8
pve-xtermjs: 4.16.0-1
qemu-server: 7.3-4
smartmontools: 7.2-pve3
spiceterm: 3.2-2
swtpm: 0.8.0~bpo11+3
vncterm: 1.7-1
zfsutils-linux: 2.1.9-pve1




balloon: 0
boot: order=scsi0
cores: 4
cpu: host
hotplug: disk,network,usb,memory,cpu
ipconfig0: ip=xxx.xxx.xxx.xxx/xx,gw=xxx.xxx.xxx.x
ipconfig1: ip=xx.xx.x.x/xx
memory: 8192
meta: creation-qemu=7.0.0,ctime=1668085785
name: Name der VM
net1: virtio=XX:XX:XX:XX:XX:XX,bridge=vmbrx,tag=xx
numa: 1
onboot: 1
ostype: win10
scsi0: datastore:vm-xx-disk-0,cache=unsafe,format=raw,iothread=1,mbps_rd=115,mbps_rd_max=300,mbps_wr=115,mbps_wr_max=300,size=1100G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=59ae716a-a009-4ea4-ab58-e3aabb9523dc
sockets: 1
tablet: 1
vga: std
vmgenid: 3e195005-0bfa-47e0-8d00-d952441d4c99




dir: local
path /var/lib/vz
content vztmpl,snippets
prune-backups keep-all=1
shared 0

zfspool: datastore
pool datastore
blocksize 64K
content images,rootdir
mountpoint /datastore
sparse 1
 
Alvin2k8 said:
Wenn wir aber auf einer Virtuellen Windows Umgebung die Festplatte verkleinern, "stirbt" der Host fast ab.
Click to expand...
Mal ganz grundsätzlich: Warum tut ihr sowas? Die VM-Disks sind doch als sparse angelegt und belegen normalerweise nur wenig mehr als nötig. Wenn Du dagegen im Gast das Filesystem verkleinerst, müssen (ähnlich wie beim defrag, was man auch nicht tun sollte) etliche Blöcke umsortiert werden und landen dann in Bereichen, die vorher gar nicht belegt waren, was dazu führt, daß die VM-Disk sogar mehr real belegt als vorher. Und weil außerdem der Gast nichts von der Blockgröße des zfs weiß, sondern mit seiner eigenen Clustergröße arbeitet, ist das Diskimage im zfs hinterher fürchterlich fragmentiert, was zu erheblicher write amplification führen kann.
 
  • Like
Reactions: Falk R. and ubu
Vermutlich killt das im Zusammenspiel mit RaidZ2 die Disks.
 
Alvin2k8 said:
Blech mit 2x AMD Epic 7282 , 512GB Ram und 8x SSDs als ZFS Storage im RaidZ2.
Click to expand...
Alvin2k8 said:
CPU Auslastung nahezu 100% und IO Verzögerung teilweise nicht mehr messbar.
Click to expand...

Frage mich, warum bei (Performance-)Problemen mit dem Storage, nie konkrete Angaben (mindestens mal die exakten Modellbezeichnungen/-nummern der Disks und ggf. des Controllers) zur verwendeten Storage-Hardware gemacht werden...

Und wie bereits gesagt wurde, RaidZ ist definitiv nicht optimal als Guest-Storage:
https://pve.proxmox.com/wiki/ZFS_on_Linux#sysadmin_zfs_raid_considerations
 
mow said:
Mal ganz grundsätzlich: Warum tut ihr sowas? Die VM-Disks sind doch als sparse angelegt und belegen normalerweise nur wenig mehr als nötig. Wenn Du dagegen im Gast das Filesystem verkleinerst, müssen (ähnlich wie beim defrag, was man auch nicht tun sollte) etliche Blöcke umsortiert werden und landen dann in Bereichen, die vorher gar nicht belegt waren, was dazu führt, daß die VM-Disk sogar mehr real belegt als vorher. Und weil außerdem der Gast nichts von der Blockgröße des zfs weiß, sondern mit seiner eigenen Clustergröße arbeitet, ist das Diskimage im zfs hinterher fürchterlich fragmentiert, was zu erheblicher write amplification führen kann.
Click to expand...
Hallo,

das müssen wir leider Kundentechnisch so machen. Da führt leider kein Weg dran vorbei.
Dabei geht es auch nicht um den Speicher am System selbst, sondern in der VM!
Die Platte an sich bleibt so groß wie Sie ist aber der "sichtbare Speicherplatz" wird reduziert in Windows!
 
Wieso arbeitet ihr nicht mit quotas?
 
Falk R. said:
Wieso arbeitet ihr nicht mit quotas?
Click to expand...
Gute Frage.
Hatten wir so noch nicht auf dem Schirm da die bisherige Methode nie Probleme gemacht hat.
Und es geht auch selten rückwärts mit dem Speicher, sondern eher vorwärts....

Aber durchaus ein guter Ansatz sich das mal näher anzusehen!

Danke!
 
Alvin2k8 said:
es sind Samsung 870 Evo mit 2TB. Dies 8x im ZFSZ2 Verbund.
Click to expand...
Das ist auch alles andere als performant.
8 Disk Raidz2 = IOPS Performance gleich schnell wie nur eine einzelne Disk, da das nur mit der Anzahl der vdevs aber nicht mit der Anzahl der Disks skaliert. Außerdem massig Padding Overhead (und damit weniger nutzbare Kapazität als mit einem Raid10), sofern du die Volblocksize nicht manuell auf mindestes 16K vergrößert hast.
Consumer SSDs ohne Power-loss Protection (PLP) = richtig miese Sync Write Performance die eher auf HDD-Niveau ist:
1679695282292-png.48421
 
Last edited:
  • Like
Reactions: mow
Dunuin said:
Das ist auch alles andere als performant.
8 Disk Raidz2 = IOPS Performance gleich schnell wie nur eine einzelne Disk, da das nur mit der Anzahl der vdevs aber nicht mit der Anzahl der Disks skaliert. Außerdem massig Padding Overhead (und damit weniger nutzbare Kapazität als mit einem Raid10), sofern du die Volblocksize nicht manuell auf mindestes 16K vergrößert hast.
Consumer SSDs ohne Power-loss Protection (PLP) = richtig miese Sync Write Performance die eher auf HDD-Niveau ist:
1679695282292-png.48421
Click to expand...
Was würdest du denn für eine ZFS Option empfehlen, bei den vorhandenen Platten?
 
Keine Option wird richtig tolle Performance liefern, da ZFS viel Sync Writes nutzt und die Evos ohne PLP da einfach schlecht sind.
Aber ein 8 Disk Striped Mirror mit ashift=12 und volblocksize=16K sollte wenigstens die 4-fache IOPS Performance erzielen. Dürfen dann aber halt nicht beide Disks eines vdevs ausfallen. Und man hätte sogar mehr nutzbare Kapazität als mit einem 8 Disk Raidz2 bei standardwerten (ashift=12 und volblocksize=8K).
"relatime=on" für den Pool kann auch noch Performance erhöhen, weil dann nicht jede Leseoperation automatisch auch eine zusätzliche Schreiboperation verursacht.
 
Last edited:
  • Like
Reactions: mow
achja...danke!
Sehe ich richtig, wenn "atime=off, relatime=on" ist das gleiche wie "atime=off,relatime=off"
Also muss atime auch on sein?

Und muss ich das bei jeder Disk aktivieren oder reicht der ZFS Pool?
 
Last edited:
Striped Mirrors sollten deutlich besser laufen und atime=on, heißt er loggt jeden Zugriff. Das erzeugt massiv Writes und bremst mal richtig.
Ein RaidZ2 sollte mehr Netto Kapazität haben, aber ist wie schon vorher erwähnt deutlich langsamer und sollte nie für VMs genutzt werden. Für Backups ist das OK.
 
  • Like
Reactions: mow
Alvin2k8 said:
Sehe ich richtig, wenn "atime=off, relatime=on" ist das gleiche wie "atime=off,relatime=off"
Click to expand...
Jup. Wenn man eh schon "atime=off" hat, dann macht "relatime=on" keinen Sinn. Und "atime=off" hätte noch bessere Performance, an hat dann ber halt auch keine atime mehr, was ja für viele Anwendungen benötigt wird (z.B. für einen PBS Datastore).
Alvin2k8 said:
Und muss ich das bei jeder Disk aktivieren oder reicht der ZFS Pool?
Click to expand...
ZFS optionen kann man nur für Pools, Datasets oder Zvols definieren, nicht für einzelne disks/vdevs.
 
  • Like
Reactions: mow
Falk R. said:
Striped Mirrors sollten deutlich besser laufen und atime=on, heißt er loggt jeden Zugriff. Das erzeugt massiv Writes und bremst mal richtig.
Ein RaidZ2 sollte mehr Netto Kapazität haben, aber ist wie schon vorher erwähnt deutlich langsamer und sollte nie für VMs genutzt werden. Für Backups ist das OK.
Click to expand...
Klingt für mich aber eher so, als hätte sich Alvin noch nicht richtig mit ZFS beschäftigt. Daher würde ich mal vermuten der Pool läuft noch mit Standardwerten (könntest du über zpool get ashift und zfs get volblocksize prüfen. Bei ashift=12 sollte volblocksize nirgends kleiner als 16K sein, bei ashift=13 nirgends volblocksize kleiner als 32K usw.) und dann würde man bei einem 8 Disk Raidz2 nur 2,66 von 8 Disks effektiv für VMs nutzen können, was dann deutlich schlechter als die 4 von 8 Disks von einem Raid10 wäre.
 
Last edited:
  • Like
Reactions: mow
You must log in or register to reply here.
Top Bottom