iSCSI Dell ME5 – Proxmox környezetben I/O wait

Szerverek

Sziasztok,

Dell ME5 storage + Proxmox VE környezetben futó iSCSI alapú storage rendszerünknél komoly I/O wait és teljesítmény-anomáliák jelentkeznek (időszakos extrém IO-wait, VM-ek megfagynak, ME5 GUI lefagy, olvasási teljesítmény szélsőségesen változó).

Firmware frissek, multipath konfig Dell ajánlás szerint, RAID10 + SSD read-cache kipróbálva, PBS mentés optimalizálva, PVE friss telepítéssel is tesztelve. A jelenség változó, de vissza-térően tapasztalható, és szeretnénk helyben szakértővel kielemezni.

Keresek olyan szakembert, aki jártas:

  • Dell ME5 / ME-sorozatú storage-ban
  • iSCSI konfigurációban (ALUA, multipath, tuning)
  • Proxmox VE storage integrációban
  • teljesítményproblémák diagnosztikájában (I/O, latency, fio, multipath-d)

Helyszín: Székesfehérvár

Olyan valakit keresek, aki személyesen, helyben is tud foglalkozni vele (nem csak távoli) és lehetőleg számlaképes.

Köszönöm!

  • 1056 megtekintés

( szekelyk | 2025. 11. 06., cs – 17:17 )

A diszk konfigurációt leírod? Csak arra gondoltam ha HDD-k vannak RAID10-ben és előtte read-cache SSD, akkor letörhet a teljesítmény ami nincs cacheben és HDD-ről kell olvasni. A szélsőségesen változó olvasási teljesítmény is erre utal, amikor nem cacheből jön az adat.

( szekelyk | 2025. 11. 06., cs – 17:23 )

Switchen és direkt kapcsolaton is ugyanaz a helyzet?

( n.balazs v | 2025. 11. 06., cs – 22:32 )

Ha írnál kicsit bővebben az architektúráról, akkor szerintem itt mi is segítenénk.

Pár apró kérdés részemről:

  • Pontosan mi a ME5 storage konfigurációja? Modell, lemezek mérete és száma, SSD mérete stb.
  • Van-e storage replikáció?
  • Hogy áll a tiering? Mit mutat az ottani statisztika?
  • Az SSD az RI vagy Mixed Use?
  • Hogy néz ki a storage és host közötti hálózat?
  • Mit lehet tudni a hostról? Hány VM fut rajta? Mekkora az overcommit rate?
  • Használtok-e thin LUN-okat?
  • Csak egy pár adott VM-nél jelentkezik a hiba vagy bármelyiknél?
  • Mit mutat a storage statisztika az írott / olvasott adatok arányára nézve?

( orkenyi | 2025. 11. 07., p – 22:47 )

Sziasztok

Köszönöm a választ megpróbálom összefoglalni jobban, de már őszintén nem hiszem hogy én meg tudom oldani....

A storage egy Dell ME5012, 10×4 TB SAS HDD RAID10-ben (512 k chunk), és van mellette egy 1,9 TB SSD read cache (RI típus). Cache policy: write-back + adaptive read-ahead. Nincs tiering vagy replikáció, csak egy pool és volume. A firmware a legfrissebb.
iSCSI-n keresztül csatlakozik, 2×25 Gbit/s round-robin ALUA multipath (Dell multipath.conf ajánlás alapján), jumbo frame aktív.

Direkt Dell dac kábelkapcsolattal (switch nélkül)

Host oldalon Proxmox VE 9 (kernel 6.14), LUN thin, kb. 15 VM fut rajta, 60–70 % overcommit mellett. A gond leginkább Proxmox Backup mentés közben jön elő, amikor az I/O wait kilő és a VM-ek megállnak. Írás 600–1000 MB/s, de olvasás néha beesik 200 MB/s alá (fio-val 13–15 MB/s is előfordult). SSD cache-szel a GUI lefagy, nélküle stabilabb, de időnként továbbra is vannak I/O delay.

A multipath konfigot másold be ide kérlek, megy egy multipath -r kimentet is!

A round-robin hol van konfigurálva?

Ezt találtam ME5 ajánlásnak.

device {
  vendor "DellEMC"
  product "ME5"
  path_grouping_policy group_by_prio
  path_checker "tur"
  hardware_handler "1 alua"
  prio "alua"
  failback immediate
  rr_weight "uniform"
  path_selector "service-time 0"
  }

Nekem a 10x4TB NL-SAS meghajtó karcsúnak tűnik IO szempontból. Mondjuk a legjobb választás még a RAID10 volt, de a sizer így is csak alig több mint 1000 iops értéket ad erre a konfigurációra akárhogy csavargatom. Az 512k chunk méreten kívül próbáltatok mást? Igaz RAID10 esetén ez az ajánlás.

A megadott írás és olvasás értékek szerintem azzal magyarázhatók, hogy az írás elnyeli a write-back cache, az olvasás esetén pedig nem cacheből jön az adat hanem a diszkekről. Szerintem backup esetén nincs jelentősége a read-cache-nek pláne a read-aheadnek.
 

Így látatlanban szerintem ez a rendszer alulméretezett. 10db HDD eleve nem sok, a 4T lemez gyaníthatóan ráadásul nem is 10k, hanem 7.2k. Ez IOPS-ban elég karcsú. VM-ek alá 7.2k lemezt tenni borítékolja a hasonló problémákat, ~15VM már elég jól tudja ráncigálni ide-oda, ahogy élik egyéni életüket, túlzott terhelésre sincs feltétlenül szükség (gondolj bele, 1 VM alá nem jut egy teljes lemez sem, az SSD ezen nyilván tud javítani, de az sem csoda).

Mindezt az is erősíti, hogy ezen leírásod alapján elsősorban mentéskor fordul elő a probléma.

Mennyi adatot ment a mentés? Ha 1,9T-nál többet, akkor könnyen kipucolódhat ez az ssd cache, a 7,2k lemez kínosan lassú lehet.

Az IOps értékeket is meg kellene nézni.

A VM-ek mit csinálnának, mikor belassúlnak? Írnának vagy olvasának? Milyen jellegű VM-ek?

Nem ismerem a tárolót, de egy ilyen cache akkor sem képes csodára. A https://www.dell.com/support/manuals/en-us/powervault-me5012/me5_series_ag/about-ssd-read-cache?guid=guid-0d8db30b-27a2-41c9-bfc5-a437c0699c64 alapján számol valami statisztikát ("as a read cache for "hot" pages only"), azaz egy mentés hatására valószínűleg nem potyog ki minden a cache-ből, de tudni kellene, hogy milyen alkalmazások vannak és mi indokolta a 4T lemez méretet (miként történt a méretezés, mi tette lehetővé a spórolást több 10k lemezhez képest).

A másik gond az, hogy az SSD cache miatt kb mérhetetlen a rendszer: nehezen fogod tudni, hogy amit mérsz, az most honnan jön és micsoda. Talán hétvégén (ha akkor nyugi van) lehetne célzott terhelésekkel lőni, majd mentést futtatni, megint terhelés stb, simán rámegy rengeteg idő, lehet, hogy valamennyit lehet ezen tuningolni, de 90% fölötti esélyt mondok arra, hogy a végső konklúzió alulméretezés lesz. Ha lesz egyáltalán explicit konklúzió.

Én cache helyett lehet, hogy megpróbálnám inkább az automatikus rétegzést, például OS lemezeket és a kritikusabb adatokat gyorsabb réteghez kötve (tiering/affinity: https://www.dell.com/support/manuals/en-us/powervault-me5012/me5_series_ag/volume-tier-affinity?guid=guid-81370bfc-2eb8-4349-8391-3465e4e4f0d8&lang=en-us), de ehhez ismét tudni kellene, hogy milyen adatból mennyi van a látatlanban ~15T (+/- 2-3T) adatból.

Qcow2-val a proxmox backup használja a dirty-bitmap-et, igy csak az előző backup óta keletkezett változásokat menti át , ha naponta keletkezik új 1,9tbájtnyi adat, akkor az durva ja, vagy LVM (gondolom azt használnak iSCSI-val) esetén nincs ilyen (vagy minden nap leállításra kerülnek a gépek, de azt kétlem?!), aztán mindig mindent be kell olvasni. De akkor meg lehet az egész mentési stratégiát át kellene alakítani, és pl. storage-en menteni közvetlenül, vagy nem LVM-et használni ha az van.

Windows szerver tud olyant csinálni különösebb erőlködés nélkül, hogy a dirty bitmap naponta 80%-nyi változást mutat, mert valami háttérfolyamat hozzányúlkál minden blokkhoz. Ha meg be van kapcsolva a discard, és fut is a Windows-on a diszk optimalizálás (default hetente 1x minden diszkre aktív), akkor 100%-ot fog mutatni a változott blokkok száma, az a VM összes diszkjét teljes terjedelemben át fogja küldeni a PBS-nek.

Mi ki szoktuk kapcsolni az automata trim-et Windows-on (pláne, hogy ha van néhány TB virtuális diszk alatta, akkor az összes memóriát is megeszi ezalatt), és megnézünk minden folyamatot, ami non-stop lemezezik, hogy az tényleg kell-e.

Ez alapján azt mondom, hogy az infra el lett tervezve (=elcseszve). Nem a 2x25 GbE lesz a hiba forrása. 

Ahogy Krisztián is írta: Ez így nagyon kevés IOPS-t tud. 5*180 = 960. Ezt akár 1-2 VM is le tudja ültetni, ha nincs Proxmox oldalon szabályozva az IO per VM alapon.
Az az RI típusú SSD sok mindenre jó. Viszont cache-nek nagyon nem. Én ezért áttenném tierbe. Cache-nek csak MU vagy WI-t érdemes tenni. Lásd, egy jó kis összefoglaló a témában: https://www.serverstor.com/read-intensive-vs-write-intensive-vs-mixed-use-ssds-whats-the-difference/

Az 512k-n kívül én kipróbálnám a 4k-s chunk méretet is. Meg kell nézni, hogy a diskek milyenek hardveresen. Az alá nem érdemes menni - persze végezz mérést is erre vonatkozóan.

A talán legsúlyosabb hiba szerintem: az adatok ugyanazon a RAID tömbön / poolban vannak, mint ahová a mentés is történik.
Disk --> Storage controller --> iSCSI --> Host --> PBS VM --> Host - iSCSI --> Storage controller --> Disk
Én mindenképp különszedném a mentésre használt tömböt. Nem tudom, te látod, hogy mekkora terület kell a mentéshez. 6x lenne a normál adatoknak, 4x a mentéshez. Mindkettő RAID10-ben. Így a mentés nem fogja meg az adat tömböt. Az SSD-t az adat tömbhöz kösd be tieringbe, ne a mentéshez.

Összefoglalva amiket én tennék:

  • Limitálnám a VM-ek IOPS-t.
  • Áttenném az SSD-t tieringbe.
  • Szétszedném a RAID tömböt 2-re: adatok, mentés.
  • Megvizsgálnám a működést 4k-s chunk mérettel is. Különösen a PBS esetén.

A talán legsúlyosabb hiba szerintem: az adatok ugyanazon a RAID tömbön / poolban vannak, mint ahová a mentés is történik

+sok A PBX az másik fizikai gépen fut (akkor tudsz további lemezt tenni bele/rá) - vagy ezen egy VM-ként? Egy 4xLFF használt servert már "gombokért" kapsz ami PBS-nek tökéletes lehet, már csak az a kérdés, h mennyi tárhelyet szeretnél mentésre, mert 10TB körüli lemezek olyan 100k körül lesznek.

Én sehol nem látom azt, hogy a mentések ugyanide mennének. Ha mégis én értettem félre valamit, akkor sem az a megoldás, hogy másik tömbre mennek, hanem konkrétan másik tárolóra/szerverre kellene tenni (persze ismerni kellene a mentési architektúrát, de az esetek túlnyomó részében a mentések a produktív tártól eltérő helyre menjenek).

Az IOps korlátozás könnyen kontraproduktív lehet.

A chunk stb paraméterekkel lehet játszani, de én nem hiszem, hogy megváltást okozna + tipikusan elég bonyolult/időigényes ezzel játszani.

Szerintem egyszerűen az történik, hogy kevés a cache, a produktív adatok annál nagyobb méretben vannak elszórva, és mikor valami nincs cache-ben, akkor csak a nagyon lassú forgó lemezeken érhető el, ami óhatatlanul lassú lesz (ráadásul ez meglehetősen nehezen mérhető ki). A mentés úgy jön képbe, hogy vagy kiszórja az adatokat a cache-ből (esetleg hozzájárul a kiszóráshoz, mert úgy jön ki a statisztika), vagy egyszerűen azért, mert mikor mentés is fut, akkor a forgó lemezek eleve terheltek, így az onnan elérendő adatok még lassabban lesznek elérhetők.

A tieringgel egyetértek, lásd feljebb (OS + teljesítmény kritikus adatok odaragasztása). Ha ez nem hoz megoldást, akkor újra kell tervezni a rendszert. Több SSD és/vagy több+gyorsabb+kisebb HDD, de ezt ennyi információ alapján képtelenség meghatározni.

Egy fiot ki tudsz próbálni: (mármint a topiknyitó)

fio --name=ssdtest --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE

ha  400-500  kB/ sec jön ki,  akkor amit elöttem írtak. iops alacsony. Illetve ha nem titok megoszthatod mennyi lett. Ez csak egy 10 megás teszt, pár másodperc.
 

https://blog.claryel.hu

A tisztán HDD alapú tömb tuti nagyon kevés erre a terhelésre. Az 512k chunk méret sem biztos, hogy ideális ilyen lassú tárolónál, és az RI SSD kb. semmire sem jó szerver környezetben (az boot meghajtónak való meg webszerver alá statikus tartalomnak), nem még bármilyen cache-nek storage-ba, sokszor rosszabb ilyennel egy kötet, mint nélküle.

Az írás-olvasási adaton látszik, hogy nagy blokkmérettel, szekvenciális művelettel nézed/mérted. A VM terhelés nem ilyen, hanem kis blokkmérettel, random írás-olvasás. Ha futtatsz egy FIO-t random rw módban, 16k blokkmérettel, az így kaptt adat inkább lesz jellemző a VM futtatásra. Szerintem elképesztően gyászos számok lesznek RAID10 ide vagy oda, én kb. 500 IOPS-t és ehhez ~8 MB/s sebsséget tippelek. Ez vicc VM-ek alá. Szóval én megfordítanám, ez csoda hogy nem tűnik fel a VM-ek teljesítményén mentés nélkül, normál futás közben...

A PBS terhelés sem szekvenciális, hanem nagyon is random, ugyanis kicsi, ~4 MB-os blokkokat használ, milliószámra - ha a PBS is erre a tömbre ment.

Egyébként ha a Proxmox-ba tesztek egy SSD pool-t (nem kell nagy, nem feltétlen kell redundáns sem, és legyen thin provision), és azt megadjátok a mentésnél fleece-nek, akkor oda gyorstárazza a mentendő dolgokat a vzdump, így kevesebb ideig lesz nagy terhelés a VM diszkeken mentés közben.

az RI SSD kb. semmire sem jó szerver környezetben (az boot meghajtónak való meg webszerver alá statikus tartalomnak), nem még bármilyen cache-nek storage-ba, sokszor rosszabb ilyennel egy kötet, mint nélküle.

Én ezt túlságosan erős állításnak tartom, pláne úgy, hogy "mögötte" 7.2k lemezek vannak (én még nem láttam 10k 4T lemezt, a tároló adatlapján sincsen), nem is túl sok (konkrétan kevés, VM-enként 1db lemez sem jut).

Persze, jobb egy MLC SSD, de ki is kell fizetni, gazdagabb/nagyobb helyeken is megszámolják, hogy 10-20T-t miből raknak össze. Tekintve, hogy semmi információ nincs az adatokról, nehéz ez ügyben okosat mondani, számomra az a biztos, hogy a 7,2k lemezek nagyon jó eséllyel hozzájárulnak a problémához.

Az RI SSD-kben nincs PLP, így (részben emiatt, részben az RI-ség miatt) csapnivaló a random írás IOPS SSD-s mércével nézve. Mi is kísérleteztünk enterprise, de RI SSD-kkel néhány éve ügyfél virtualicció szerverbe, hogy olcsóbb legyen, de eléggé vegyes, inkább rossz tapasztalataink lettek teljesítmény terén.

Ezért mi MU SSD-ket teszünk szerverbe és NAS-ba VM tárolónak és cache-nek. Persze ahol sok adat van (főleg fájlszerver funkció, nem SQL alá), oda teszünk HDD-t is a sok, nem túl IOPS igényes adatnak, nem tisztán SSD-sek a szerverek. Mi jellemzően Kingston DC600M-et veszünk az utóbbi időben, régebben Samsumg PM sorozatot részesítettük előnyben. 1-2-4 TB méretben ezek azért kifizethetők egy szerverbe 2-4 darab. Mellé mehet valamilyen Exos diszk tárkapacitásnak, és már kész is költséghatékényan egy aránylag gyors Proxmox szerver.

Storage-dzsel pont azért nem próbálkozunk a legtöbb ügyfélnél (mi kisebb cégeknek, hivataloknak dolgozunk jellemzően), mert azok általában nagyon háklisak a betett meghajtókra (szeretnek márkahűek lenni, és egy Dell MU SSD arcpirító árban van), inkább csinálunk Ceph-fel osztott tárkapacitást, ha ilyen igény merülne fel. Abból is SSD és HDD pool-okat egyaránt az adattól függően.

( asm v | 2025. 11. 07., p – 23:13 )

Szerintem erdemes korulnezni a TCP Delayed Ack es az iSCSI Queue Depth beallitasok korul.

( szekelyk | 2025. 11. 09., v – 00:05 )

PowerVault ME50xx    

Latest code: 1.2.1.5    August 2025  

Recommended code: 1.2.0.3    May 2024   

Minimum supported code: 1.2.0.2    Oct 2023

( gabrielakos v | 2025. 11. 10., h – 08:59 )

proxmox backup jobok szervezéséről sem tudunk semmit.

célszerű úgy szervezni hogy ne zavarjon: 

  • csinálni mondjuk egy napi_mentes jobot és abba belerakni az összes vm-et amit mentenél
  • csinálni másik akármilyen mentéseket, ami akkor fut miután az első már várhatóan végzett

A lényeg az hogy egyszerre lehetőleg egy (v kevés) job fusson, az nem fogja agyonvágni a diszket.

Az inkrementális mentés miatt ez se fog drámaian sokáig tartani.

Amit még lehet: pbs inbound sávszélességet limitálni, de hogy ezt hol és hogyan - na ahhoz konkrétan látni kellene az egész infrát.

( wolfnet | 2025. 11. 14., p – 12:01 )

Sziasztok, Farkas Márk vagyok, Örkényi Petivel dolgozunk együtt a dell emc projekten. Olvastam a válaszaitokat, a teljesség igénye nélkül próbálok válaszolni. 

  • a Proxmox backup egyértelműen nagy latency-t okoz, 30-35% iowaitet nem ritkán. 15-20 perces inkrementális snapshot mentések vannak, tehát folyamatosan fut. Nem napi egy vagy ilyesmi, üzemeltetési szempontból nekünk nagyon fontos a legalább fél óránkénti mentés. A háttérben a backup szerver napi 1x rendezi a mentéseket. Ha korlátozzuk a backup szálakat és erőforrást jobb a szitu. A problémánk az hogy ha natívan fut valamelyik dell szerver merevlemezein a VM és úgy mentjük ugyan így, nincs iowait probléma nincs VM lagg. A natív storage megoldáskor ráadásul nem SAS merevmelezekkel dolgoziunk hanem sima 4TB WD PURPLE / RED vinyókkal, amelyek "lassúak", még sincs iowait gond csak ha EMC-n lévő VM-et mentünk.
  • A mentések alkalmanként kb 5-15GB méretet mentenek le. Ha újra fut tisztán akkor 500-800GB méretűek a VM diskek, ilyenkor megértem az iowaitet, de utána nem.
  • Eredeti DELL SAS 10GBPS 3.5" merevlemezeket használunk! Eredeti DELL SSD -t használunk cache-ra.
  • Próbáltunk mindent, próbáltunk korlátozni VM iops-t picit jobb de nem jó. Van olyan VM amelyik csak DB postgresql, van olyan vm 3-4 ami windows 11 / windows szerver. A többi ubuntu server.
  • A roundrobint debian multipath szinten próbáltuk. Nélküle a csúcs sebesség alacsonyabb, vele a csúcs sebesség 1200MB/S írás kb. Ami hibátkannak tartok nekünk bőven elég. Viszont tényleg itt kizárólag ilyen "LAGG" problémák vannak, elindul egy mentés és azonnal "megfagy" 1-1 vm. Ami főleg ADATBÁZIS műveletnél kínos... :D 

Én azt javaslom akinek van konkrét tapasztalata, Pénzért, nem ingyen várjuk el, és Székesfehérvár megközelíthető távolságban van neki, kérem telefonon / emailen keressen meg minket, egyeztessünk egy napot amikor kijön megnézi, kifizetjük a kiszállását, kifizetjük az idejét, biztosítunk végtelen Kávét és Pizzát :)))  és tudunk Tesztelni játszani úgymond, az egész DELL EMC le van resetelve jelenleg. Megnézhetjük elölről együtt, aki érez magában affinitást és van ideje foglalkozni vele és tudja mit csinál kérem jelentkezzen. 

 

wolfnetteam@gmail.com

06 30 241 7826 

köszönjük és reméljük találunk alkalmas embert

üdv Márk

raid6 na az a tipikus oltári kibaszás mindennel.

nézd már meg hogy egy darab írás (a backup ugye írás) az mennyi plusz olvasást és checksumot eredményez. elméleti szinten.

ennyivel már oszthatod is tovább a rendelkezésre álló iops-t. Marad 15 iops-ed? Csodálkozol?

Még egyszer leírjuk hogy IOPS-nek hívják ami miatt a bajod van. Meg latency-nek.

Ha "elraksz" egy disket storage-ba akkor a natív latencyhez még az a késleltetés is hozzájön amíg a géptől a storage-ig elér a kérés meg vissza.

Arról nem is beszélve amit a "storage-ban" eltölt.

Szóval egy ilyen diszk alapból tud mondjuk 100-120 iops-t. Ha 4k-s írások vannak akkor ez 400kbyte/sec.

A 100 iops ugye átlagban 10msec latency-t ad neked. Ehhez adjál még mondjuk kettőt a storage miatt (és optimista voltam) máris ott tartasz hogy 12ms. Ott tartasz hogy 83 IOPS az elméleti maximumod. 

Mire elég ez?

Leirták előttem , utánam.  Jó átersztő képesség, gyenge iops. ISCSI , minden I/O műveletet TCP/IP csomagokba kell „becsomagolni”, majd a hálózaton továbbítani. Purple-nél meg nincs hálózati réteg.  Egy aszatli ssd , a leggyengébb is jobb lesz mint a Dell. 
Próbáljátok már kia a fio-t amit már irtam, illetve hogy mennyi lett : (a testfile1  file a dell-en jöjjön létre):

fio --name=dell test --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE

 

https://blog.claryel.hu

kipróbáltam pár diszken:

nvme ssd single (eléggé dolgozik):
root@dell:/mpool# fio --name="dell test" --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE
 WRITE: bw=23.3MiB/s (24.4MB/s), 23.3MiB/s-23.3MiB/s (24.4MB/s-24.4MB/s), io=10.0MiB (10.5MB), run=430-430msec

15 k sas raid 1 (2) nem csinál semmit:
root@dell:/rpool# fio --name="dell test" --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE
 WRITE: bw=915KiB/s (937kB/s), 915KiB/s-915KiB/s (937kB/s-937kB/s), io=10.0MiB (10.5MB), run=11191-11191msec

régi intel enterprise ssd raid1 (2) nem csinál semmit:
root@dell:/spool# fio --name="dell test" --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE
 WRITE: bw=9517KiB/s (9745kB/s), 9517KiB/s-9517KiB/s (9745kB/s-9745kB/s), io=10.0MiB (10.5MB), run=1076-1076msec

synology nas nfs (benne nvme ssd raid1 write cache, idle):

root@dell:/mnt/pve/proxmoxbk# fio --name="dell test" --filename=testfile1 --size=10M --bs=4k --iodepth=1 --rw=randwrite --randrepeat=1 --sync=1 --fsync=1|grep WRITE
 WRITE: bw=10.4MiB/s (11.0MB/s), 10.4MiB/s-10.4MiB/s (11.0MB/s-11.0MB/s), io=10.0MiB (10.5MB), run=957-957msec

Elég pici ez a tesztfile de asszem látszik a diszkek hátránya így is. Pedig lokál diszkek.
A gépben levő NVME SSD-t pedig a PCIe busz sávszél korlátozza, az SSD többet tudna. (Dell R430, jó régi)

  • A mentések alkalmanként kb 5-15GB méretet mentenek le. Ha újra fut tisztán akkor 500-800GB méretűek a VM diskek, ilyenkor megértem az iowaitet, de utána nem.

Ez egy hibás állítás. Egy ekkora "VM inkrementális mentés" is bőven előhozza ugyanazokat a problémákat mint egy full mentés.

( vasla_ | 2025. 11. 14., p – 13:41 )

Ok, látszik ezen a mini teszten is   nativ sas: 937kB/s iops terhelésnél (150-200)  ,  iscsi nél még rájön a hálózati réteg, ami már lehet hogy nagyon levesz. Az ssd-kkel nincsenek egy univerzumban. HDD-kkel én olyan 100 ra tippelem a dell-t.

https://blog.claryel.hu

( vasla_ | 2025. 11. 14., p – 13:51 )

Na most találgatások helyett nem lenne célszerűbb megcsinálni két fiot, egyet a dell lemezekre egyet meg a nativ purple lemezekre. Ha másre nem,  összehasonlitásra jó. 
Vagy elmélkedhetünk , hogy szopik e a kacsa ?

https://blog.claryel.hu

( gabrielakos v | 2025. 11. 14., p – 14:06 )

RAM ról még nem beszéltünk. Mennyi ram van a gépben és ebből mennyi jut a VM-eknek / mennyi marad filesystem cache-nek?
Nálam a ZFS eléggé "szárnyakat kapott" amikor kapott +64GB-t a szerver. Most 160GB van benne, swap nincs.