ZFS i.c.m. ESXi en RDM zonder VT-D

[sloth]

Op dit moment beschik ik over een ESXi setup die helaas geen VT-D ondersteuning heeft.
Hier wil ik een guest op draaien met ZFS als filesystem, zoals bijvoorbeeld kan met ZFSguru of FreeNAS.

Om een hdd door te geven aan deze guest moet je van RDM gebruik maken. Hierbij kan de guest niet direct communiceren met de disk.
Ervaringen van anderen met een vergelijkbare setup melden vaak errors op hun pool. Dit zou net te wijten zijn aan de 'vertaalslag' die ESXi maakt om de guest toegang tot een hd te geven.

Tweaker RudolfR meldt dat je door een RDM met parameter -r aan te maken geen errors meer hebt, maar helaas wel hierdoor SMART en spindown functionaliteit verliest:

quote: RudolfR

Doordat ik de RDMs aanmaak met -r ipv -z, heb ik geen S.M.A.R.T en geen spindown.
Maar met -z kreeg ik errors in m'n pool, dus er zat niets anders op.

Kan iemand bevestigen of ontkrachten dat je dus zonder een VT-D compatible build:

-errors op je pool hebt, maar wel SMART en spindown
OF
-geen errors hebt, en SMART en spindown ondersteuning verliest?

[Pirtkoei]

Mijn MicroServer N36L ondersteund ook geen VT-d (of IOMMU zoals AMD dat noemt), dus heb ik een tijdje ESXi 5.0u1 gedraaid met een ZFSguru 0.2-beta5 vm. De vm had ik de schijven doorgegeven met behulp van RDM's aangemaakt met de -z parameter aan de hand van de howto van David Warburton.

Smart en spindown werken gewoon zoals bij een bare metal install, geen problemen mee ervaren.

Het probleem wat ik wel had en niet heb kunnen tackelen, traaaaagg. Bare metal is de setup bijna 2,5x zo snel

[sloth]

Heb je hierbij ook je pool gecheckt op errors? Draai je deze setup nog momenteel?

Wat moet ik me bij 2,5x zo traag voorstellen, een sequential read / write die 2,5x trager is dan origineel? Heb je hier toevallig nog benchmarks van?

[Pirtkoei]

Ik heb geen plaatsje bewaard van de benchmarks, maar de resultaten waren op zowel seq r/w als iops veel trager.

Check op pool errors heb ik toen wel gedaan en niet gevonden, maar ik zal eens rebooten naar ESXi om nog eens te checken.

[Pirtkoei]

Zoals beloofd benchmarks:

Op ESXi:

ZFSguru 0.2.0-beta5 pool benchmark
Pool            : datapool (5.44T, 28% full)
Test size       : 16 GiB
Data source     : /dev/zero
Read throughput : 156.1 MB/s = 148.9 MiB/s
Write throughput: 80.6 MB/s = 76.9 MiB/s

Zonder ESXi

ZFSguru 0.2.0-beta5 pool benchmark
Pool            : datapool (5.44T, 28% full)
Test size       : 16 GiB
Data source     : /dev/zero
Read throughput : 266.2 MB/s = 253.9 MiB/s
Write throughput: 185.6 MB/s = 177 MiB/s

Het is dus niet helemaal overal x2 en de vorige keer dat ik benchmarkte stond er nog geen data op de pool.

[Anoniem: 15758]

Wat voor config is dat Pirtkoei? Want dat zijn vrij slechte scores over gigabit. Ben benieuwd naar je pool config en systeem config?

[Pirtkoei]

#	Product	Prijs	Subtotaal
2	Kingston DataTraveler 8GB	€ 14,40	€ 28,80
4	Western Digital Caviar Green WD15EADS, 1.5TB	€ 0,-	€ 0,-
1	Kingston ValueRAM KVR1333D3N9K2/8G	€ 41,68	€ 41,68
1	HP Proliant Microserver N36L	€ 226,42	€ 226,42
Bekijk collectie Importeer producten		Totaal	€ 296,90

Met RaidZ pool van de 4 WD15EADS (weet dat 4 niet ideaal is maar had de schijven nog liggen) en ZFS-on-Root installatie op de USB-stick.
Met LZJB en Fetcher4 op de share.

Netwerksnelheid heb ik ook getest met iPerf en daarmee haal ik gewoon GBit snelheden...

[Anoniem: 15758]

Ah je comprimeert alles. Als je dat eens uitzet op de share en overnieuw test, krijg je dan wel normale snelheden?

[Pirtkoei]

Zal ik morgen eens testen.

Maar het ging me vooral aan te geven aan TS het verschil tussen ESXi met RDMs en 'bare metal'.

Op ESXi heb ik eerder overigens wel met en zonder compressie getest en dat maakte amper uit...

[sloth]

Pirtkoei, bedankt voor de benchmarks / opvolging!

Je haalt inderdaad flink lagere snelheden met ESXi. Vooral de write performance is minder dan de helft dan zonder.
Zijn de lage sequential CrystalDiskMark scores te verklaren doordat je deze via een share via NIFS/CIFS/ oid doet?

Verder ben ik echt benieuwd of je nu een VT-D compatible setup nodig hebt, of een dedicated build om ZFS goed te kunnen gebruiken, dus zonder errors en met spindown en SMART ondersteuning.
CiPHER, mogelijk dat jij hier wat over kan zeggen?

[Pirtkoei]

sloth schreef op dinsdag 24 juli 2012 @ 18:09:
Zijn de lage sequential CrystalDiskMark scores te verklaren doordat je deze via een share via NIFS/CIFS/ oid doet?

Ja de combi van samba en compressie/dedup (denk ik)....

[Anoniem: 15758]

Haha ook nog dedup. Dan zijn dit nog best mooie scores, maar zo'n grote dataset heb je nog niet. Wacht maar tot de deduptables niet meer in je RAM passen, dan gaat het bruut traag worden.

[Pirtkoei]

Je hoort mij ook niet klagen

Alleen jammer dat ESXi zo'n knauw geeft... Ik had er graag nog wat bij gezet.

[FireDrunk]

Ik vind het heel vreemd, ik ben dezelfde tests nu ook aan het doen, resultaten volgen nog.
Initieel doe ik via dd exact dezelfde snelheid via RDM als native (144MB/s lezen en 141MB/s schrijven) op een Samsung F4EG 2TB die via RDM is doorgegeven.

[- peter -]

Ik begrijp ook, en hopelijk met mij de topicstarter, dat VT-D niet betekend dat je zomaar je sata controller kan doorgeven. Althans, mijn VT-D enabled setup geven niet de sata controller weer. Misschien als je een externe Sata controller kaart heb of dergelijke dat het wel lukt. Of ligt dat meer aan mijn moederbord?

[FireDrunk]

Kun je wel andere devices doorgeven via VT-d? Want het is vreemd dat een device niet in de lijst staat.
Wel kan het zijn dat het device bijvoorbeeld achter een PCI controller zit die geen SR-IOV ondersteund.
Dan kan je VT-d inderdaad niet gebruiken, maar dat merk je meestal pas ná de reboot die verplicht is bij ESXi

[- peter -]

Ja, wel andere devices, hd audio, een losse pci kaart etc. Maar goed, dat is misschien beetje te offtopic hier.

[sloth]

Eigenlijk wel, ik zou namelijk graag willen weten wat mogelijk is zonder VT-D.

[FireDrunk]

Hoezo "Wat mogelijk is"? Je kan RDM gebruiken en USB doorgeven, meer niet?
Waar doel je op?

[sloth]

Quote uit de TS:

Kan iemand bevestigen of ontkrachten dat je dus zonder een VT-D compatible build:

-errors op je pool hebt, maar wel SMART en spindown
OF
-geen errors hebt, en SMART en spindown ondersteuning verliest?

In het scenario van een enkele disk die via RDM doorgegeven wordt (met vmkfstools -z) op een onboard sata poort van een H61 chipset (moederbord is DH61WWB3)

[Pirtkoei]

Zoals beloofd ook nog een benchmark zonder compression en deduplication.
De write wordt wel een 'beetje' beter maar waarom de read dan weer minder is, schiet mij maar lek.

[Sleepie]

FireDrunk schreef op dinsdag 24 juli 2012 @ 20:53:
Ik vind het heel vreemd, ik ben dezelfde tests nu ook aan het doen, resultaten volgen nog.
Initieel doe ik via dd exact dezelfde snelheid via RDM als native (144MB/s lezen en 141MB/s schrijven) op een Samsung F4EG 2TB die via RDM is doorgegeven.

Zou je precies kunnen aangeven met welke paramaters je de RDM hebt gemaakt?
En kun je ook nog steeds SMART data uitlezen van die schijf?

[FireDrunk]

vmkfstools -z /vmfs/devices/[lange naam] /vmfs/volumes/SAMSUNG_SSD/2TB_RDM.vmdk

Meer niet...

SMART doet het ook.

[ Voor 9% gewijzigd door FireDrunk op 25-07-2012 12:42 ]

[Sleepie]

Ok helemaal duidelijk. Thanks

Ik wil mijn ZFS machine ombouwen naar een virtual machine onder ESX, maar ook ik lees wisselende verhalen over het succes hiervan.
Ik heb het al eens eerder geprobeerd, toen ging het hopeloos mis (de disks die via RDM waren doorgegeven werden constant uit de pool gegooid). Wat ik nog uit mijn 'documentatie' kan terugvinden heb ik dat toen echter met de vmkfstools -r optie gedaan, dat lijkt dus niet de juiste optie.

[FireDrunk]

-z schijnt soms errors te veroorzaken op je pool. Ik ben nog aan het testen.

[Sleepie]

FireDrunk schreef op woensdag 25 juli 2012 @ 12:45:
-z schijnt soms errors te veroorzaken op je pool. Ik ben nog aan het testen.

Da's een beetje het probleem, je leest wisselende verhalen.

Overigens nog wat verder gezocht en ik weet 99% zeker dat ik indertijd de -r optie gebruikt heb, wat dus sowieso geen succes was. Al geven anderen weer aan dat dat wel lukt, maar dan met verlies van SMART en spindown functionaliteit.

Ik wacht in spanning je test-resultaten af

[ Voor 10% gewijzigd door Sleepie op 25-07-2012 12:56 ]

[sloth]

* sloth ook, we zijn eindelijk bij de essentie van dit topic aanbeland

[FireDrunk]

[root@zfsguru /lala/share]# bonnie++ -d /lala/share -u ssh
Using uid:44, gid:44.
Writing a byte at a time...done
Writing intelligently...done
Rewriting...
done
Reading a byte at a time...done
Reading intelligently...done
start 'em...done...done...done...done...done...
Create files in sequential order...done.
Stat files in sequential order...done.
Delete files in sequential order...done.
Create files in random order...done.
Stat files in random order...done.
Delete files in random order...done.
Version  1.96       ------Sequential Output------ --Sequential Input- --Random-
Concurrency   1     -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
zfsguru.bsd     32G   121  99 103929  26 55675  14   299  91 141534  15 105.0   3
Latency             75572us     698ms    3669ms     911ms     450ms    4282ms
Version  1.96       ------Sequential Create------ --------Random Create--------
zfsguru.bsd         -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 17491  95 +++++ +++ 18890  97 17979  96 +++++ +++ 19022  98
Latency             12570us     257us     796us   27580us    1058us     510us
1.96,1.96,zfsguru.bsd,1,1343190251,32G,,121,99,103929,26,55675,14,299,91,141534,15,105.0,3,16,,,,,17491,95,+++++,+++,18890,97,17979,96,+++++,+++,19022,98,75572us,698ms,3669ms,911ms,450ms,4282ms,12570us,257us,796us,27580us,1058us,510us

[root@zfsguru /lala/share]# zpool status
  pool: lala
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        lala        ONLINE       0     0     0
          gpt/lala  ONLINE       0     0     0

errors: No known data errors

  pool: rp
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        rp          ONLINE       0     0     0
          gpt/rp    ONLINE       0     0     0

errors: No known data errors

Tja, of dit voldoende is?

Net ook een scrub gedaan, en 0 errors.

[Sleepie]

Het ziet er in ieder geval goed uit, geen errors

Misschien als laatste test nog even een 2 GB testfile ofzo maken en die een keer via een share heen en weer kopieren? Als het allemaal niet teveel moeite is.
* Sleepie is je sowieso al dankbaar

[FireDrunk]

Er is al 32GB geschreven op de disk (Bonnie++ deed een test van 32G)
Vanwaar de share test?

[Sleepie]

Ik ken bonnie++ niet en zie nu de 32GB staan, ik had er overheen gekeken, sorry.
In dat geval is inderdaad alles wel getest een RDM gemaakt met de -z optie zou dus gewoon moeten werken.

Komt ook omdat ik me nog steeds niet echt lekker voel bij het idee om mijn bestaande pool over te hevelen naar een ESX VM. In principe zou het allemaal goed moeten gaan, maar juist omdat er 2 disks op het mobo aangesloten zitten en ik met RDMs moet gaan werken, ben ik er wat huiverig voor.
Helaas nergens plaats om alle data tijdelijk op te slaan en een nieuwe pool te maken, dat zou ik het liefste doen.

[ Voor 52% gewijzigd door Sleepie op 25-07-2012 15:28 ]

[FireDrunk]

Ik zal wel even SMB testen, en misschien een poosje zo laten staan. Ik kan er zelfs via NFS een VM op draaien vanaf de Host, misschien dat dat wel een goede test is.

[Sleepie]

FireDrunk schreef op woensdag 25 juli 2012 @ 15:27:
Ik zal wel even SMB testen, en misschien een poosje zo laten staan. Ik kan er zelfs via NFS een VM op draaien vanaf de Host, misschien dat dat wel een goede test is.

Dat is iets wat ik inderdaad zou willen gaan doen, op exact die manier.
Als dat gewoon werkt, lijkt me niet dat je nog problemen kunt verwachten verder.
Dan ga ik de knoop toch maar doorhakken dit weekend en mn bestaande ZFSGuru install virtualiseren.

[FireDrunk]

root@NAS:~# mount -t cifs 192.168.1.115:/share /mnt/zfs
Password:
root@NAS:~# cd /mnt/zfs
root@NAS:/mnt/zfs# ls
root@NAS:/mnt/zfs# dd if=/dev/zero of=/mnt/zfs/test.000 bs=1M count=1024
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 7.31052 s, 147 MB/s
root@NAS:/mnt/zfs# dd if=test.000 of=/dev/null bs=1M
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 9.44487 s, 114 MB/s
root@NAS:/mnt/zfs#

Share werkt iig...

[sloth]

Erg bedankt voor je test FireDrunk!

Native sequential read&write, SMART werkende en vooralsnog geen errors.
Dit ziet er erg goed uit

Zou je indien je kan en wil nog een tijdje wat write activiteit kunnen doen en met scrub op integriteit te controleren?

Wat zijn trouwens de hardware specs van je testlab? Je gebruikt sowieso 10 Gbps adapters aan de uitmuntende resultaten over CIFS te zien?
En als je toch bezig bent zou je dan ook spindown kunnen testen?

Verder vind ik het wel nog altijd bizar dat je op het internet best veel leest over errors met dit soort configuratie.
Zou het echt van setup tot setup afhangen of dit goed werkt?

[ Voor 6% gewijzigd door sloth op 25-07-2012 17:14 ]

[Proc]

Ik heb een FreeNAS 8.0.4-p2 x64 install gedaan op ESXi 5.0 U1 op basis van een RDM met -z optie. Ik heb een RAID-Z2 pool van bruto 4x 1TB aangemaakt (dus netto ca. 2 TB beschikbaar). Bij mij gaat dat al ca. 3 maanden goed (ik heb meer dan 900GB weggeschreven en geen fouten kunnen ontdekken ook niet na een scrub).

Bij mij werkt SMART goed (na de optie -d sat mee gegeven te hebben), maar powermanagement en spindown krijg ik toch echt niet voor elkaar.

Heeft iemand dat WEL werkend gekregen met een vergelijkbare FreeNAS 8.0.4 configuratie? Maakt het (veel) uit of je FreeNAS 8.0.4 gebruikt of de wat nieuwere FreeNAS 8.2.0 wat betreft powermanagement en spindown van de RDM disks?

Maakt het trouwens wat betreft spindown (veel) uit of je FreeNAS of ZFSguru gebruikt? Heb je dus bijvoorbeeld meer mogelijkheden wat betreft powermanagement en spindown van de RDM disks als je ZFSguru gebruikt i.p.v. FreeNAS?

[FireDrunk]

FreeNAS 8.04 is nanoBSD en we hebben het hier over ZFSguru dat gebaseerd is op FreeBSD 9.0.
Allicht zit daar een verschil...

[sloth]

Hoopvolle ervaringen Proc, ook jij bedankt voor je input

Mogelijk dat het wel kan met spindown. Alleen twijfel ik of je dat op FreeNAS werkende gaat krijgen, omdat je zoals FireDrunk zegt op een nanoBSD platform werkt.

Zou je je setup willen posten? Zo kunnen we proberen uit te vinden of de zfs errors mogelijk hardware gerelateerd zijn.

[FireDrunk]

Ik draai het op een Dual Xeon E5620 met 96GB geheugen, dus of dat nou belangrijk is, ik denk het niet.
Het is gewoon een Sandy Bridge SATA Controller die in AHCI mode draait, en als controller type van de VM heb ik LSI Logic SAS gebruikt.

[johnkeates]

Heb je al gekeken of het niet gewoon een beperking van ESX is? Xen zou het bijvoorbeeld een stuk beter kunnen doen...

[FireDrunk]

Oh? Waarom?

[Anoniem: 15758]

Nouja Xen zou het beter kunnen; momenteel werkt dit nog niet goed genoeg. Bij Xen is het echter vereist dat de 'guest' kernel PV-aware is, en dus in feite ondersteuning heeft voor Xen DomU. Op dit moment kan FreeBSD voor 32-bit platform met PV drivers draaien, maar voor 64-bit is het nog 'emulatie' virtualisatie. Ik hou niet zo van dit soort legacy opstellingen. Ik zie heel graag dat iets als Xen goed bruikbaar wordt. Dan heb je in feite geen verlies, 100% controle over de disks (je hebt PCI passthrough met Xen) en in feite wordt er niets geëmuleerd, wat wel bij klassieke virtualisatie (HVM) het geval is.

[FireDrunk]

PCI Passthrough is in feite gewoon VT-d maar dan met software emulatie, en verschilt dus niet anders. In de guest heb je nog steeds een fake PCIe bus.

Paravirtualisatie wil niet zeggen dat je geen emulatie meer hebt. Enige is dat de Emulatie zo dun is, dat het je amper latency/cpupower/whatever kost.

Er word *altijd* wel *iets* geemuleerd, want je kan nou eenmaal geen twee bazen van 1 stuk hardware hebben. 1 OS vangt het interrupt op van de hardware, en doet daar wat mee.

Hoe het in je guest land, is altijd iets geemuleerds, welk OS je ook gebruikt.

Dat is dus anders dan met VT-d (waar het interrupt in de guest afgaat.)

---

Ook als je (zoals Linux dat kent, en dus Xen vast ook) een hele disk aan een VM geeft, word er nog steeds een virtuele controller gepresenteerd, en juist daar zit het probleem (alsook met VMWare Paravirtual).

[ Voor 14% gewijzigd door FireDrunk op 25-07-2012 22:39 ]

[Anoniem: 15758]

Het idee van PV is dat de guest kernel ook 'aware' is van het feit dat hij gevirtualiseerd wordt, en daarmee hardware gemakkelijker en directer gedeeld kan worden. Althans, zo heb ik het begrepen.

HVM wil zeggen dat eigenlijk een hele PC geëmuleerd wordt. Alleen pure CPU instructies kennen dan weinig overhead, maar zodra een storage device of video of USB aangesproken wordt, zit er een heftige overhead aan vast. Dit zou veel minder het geval moeten zijn bij PV, wat wel vereist dat alle kernels (host en guest VMs) met elkaar samenwerken.

Wat je zegt over PCIe interface is interessant. Je zegt dat Xen met PCI passthrough dus met een geëmuleerde PCI bus werkt, en interrupts dus ook moet 'vertalen'? Dit anders dan vt-d, die wel native toegang tot de PCIe interface geeft?

Ik ben wel benieuwd hoe het nu precies werkt allemaal. In elk geval is belangrijk dat de guest VM de storage controller zelf direct kan zien, en dat het dus ook echt native en exclusieve toegang heeft tot de disks. In dit geval zou bijvoorbeeld TRIM/UNMAP ook moeten werken, iets wat niet werkt als je enkel een 'disk' meegeeft die gepresenteerd wordt via een geëmuleerde controller.

Phoronix heeft soms benchmarks van Xen enzo. Maar ik zou als Xen goed werkt met FreeBSD (10?) dit graag zelf eens testen en in het bijzonder de ZFS performance.

[Ultra]

Op http://wiki.xen.org/wiki/XenPCIpassthrough staat het wel aardig uitgelegd. Ik dacht dat VT-d een vereiste was voor PCI passthrough, maar Xen kan het voor PV guests blijkbaar zonder (maar "This can be potentially insecure and unstable").

[FireDrunk]

@CiPHER, Wat jij zegt klinkt leuk, maar *hoe* geef je native en exclusive access? Welke controller gebruik je? Wat is het pad van de signalen? Gaan ze van Guest kernel, naar host kernel, naar disk? Zo ja, welke drivers worden er gebruikt? Wat zijn de capabilities van die drivers?

Als daar geen TRIM/UNMAP in zit, kan je device het dus vrolijk ondersteunen, én kan je guest het ondersteunen, maar als de laag ertussen het niet ondersteund, kun je fluiten naar je TRIM support.

@Ultra, dat potential insecure is dus heel logisch, omdat er interrupt emulatie gebeurt, stel dat je guest interrupts gaat opvragen van andere devices

PV domU kernel needs to have the Xen PCI frontend driver loaded for PCI passthru to work! This driver is called xen-pcifront in pvops kernels.

Je moet dus én een speciale driver laden, én een PV kernel. En het risico zit hem dus in die driver.

[ Voor 17% gewijzigd door FireDrunk op 26-07-2012 09:13 ]

[Ultra]

Voor zover ik het begrijp werkt het zo: met IOMMU/VT-d en een los PCI(e)-device kan 1 PV- of HVM-guest direct dat device aanspreken, zonder dat de host ertussen zit of iets emuleert.
Hier bijvoorbeeld iemand die een voor de hypervisor unknown device, een DVB-kaart, doorlust.

[Anoniem: 15758]

@FireDrunk: in de link van Ultra lees ik dat de guest een driver voor de PCI kaart moet hebben, net als in een bare metal setup. Kortom, als BSD met native drivers met een PCI kaart communiceert, zie ik niet wat er tussenin zou kunnen zitten wat bijvoorbeeld TRIM kan verstoren. Hooguit worden interrupts dan geëmuleerd zoals je zegt, iets waar ik natuurlijk erg benieuwd naar ben.

Maar wat 'we' willen is toch dat de guest zo native mogelijk toegang heeft tot de storage controller? En voor Windows met passthrough grafische kaart zal hetzelfde gelden; je wilt niet dat de host drivers heeft en een virtuele videokaart maakt; je wilt je guest direct toegang geven tot de GPU en dus ook échte drivers gebruikt.

Maar dit is een onderwerp waar ik nog veel bij kan leren. Zou enorm gaaf zijn als FreeBSD deftige Xen support krijgt.

[FireDrunk]

Wat je zegt klopt, maar geld dus alleen voor VT-d. Bij die 'vieze' PCI passthrough heb je een speciale driver nodig die de informatie ontvangt van de host kernel. Je kan dat een beetje zien als een service bus waarover de PCI data gaat. Die driver emuleerd daarna het PCI device weer, en daarop komen weer de originele drivers van de maker van de kaart.

Effectief is er dus nooit MSI/MSI-X te krijgen, want als je *dat* gaat emuleren, krijg je een beetje hetzelfde verhaal als het willen capturen van HDMI signaal. Daar heb je een dual Xeon voor nodig, om het uberhaupt te laten performen.

Voor een simpel USB kaartje wat met PCI 1.0 werkt (Of een COM poort kaart whatever) zal het misschien nog wel werken met die STUB driver, maar zodra er écht performance nodig is, heb je echt VT-d nodig.

Ik kan wel een keer uitleggen hoe DMA werkt en hoe dat zich weerhoudt tot VT-d maar dat past een beetje slecht in dit topic.

[ Voor 6% gewijzigd door FireDrunk op 26-07-2012 18:10 ]

[Ultra]

Ik weet niet hoor, maar op diezelfde pagina staat over de niet-VT-d PCI passthrough:

updated pcifront/pciback patches with MSI/MSI-X support

[FireDrunk]

Als ze dat aan hebben, hebben ze full DMA access vanuit de guest naar de host open staan.
Met andere woorden, 1 goede memory call en je kan ALLES in de host slopen...

En het lastige is dus, je hebt een PV kernel nodig.

Ik moet zeggen dat ik wel benieuwd ben naar de performance, als ik het zo lees, hebben ze gewoon een hele smerige manier gemaakt om geheugen 1 op 1 door te geven, wat dus in theorie heel snel zou moeten kunnen.

Misschien maar eens een PoC doen met mijn 10Gb kaartjes

[ Voor 52% gewijzigd door FireDrunk op 26-07-2012 19:25 ]

[Anoniem: 15758]

Met andere woorden, 1 goede memory call en je kan ALLES in de host slopen...

Dat is het nadeel van PV toch? Dat werkt goed als de guests zich aan de 'regels' houden maar bugs hebben dus zowel de potentie om instabiliteit/corruptie/crashes te veroorzaken alsmede een security risk vormen dat ze toegang tot de host krijgen (theoretisch).

Maar een setup met PV veronderstelt dat de guest VM te vertrouwen is en op kernel niveau geen bugs/issues zijn die bovengenoemde problemen veroorzaken. Applicaties op userland-niveau kunnen dan niet de instabiliteit of onveiligheid veroorzaken; alleen bugs in de kernel-level implementatie van de PV-aware kernel (modules).

Vul aan / corrigeer waar nodig. Maar ik denk dat PV behalve voor hosting erg interessant is.

[FireDrunk]

Theoretisch gezien heb je inderdaad gelijk, maar het probleem zit hem er in, dat er meer is dan alleen DMA volgens mij. Als je bijvoorbeeld Multidevice hebt (zoals netwerkkaarten, die 2 NIC's op 1 kaart hebben) die delen de PCIe bus, en volgens mij ook redelijk wat DMA gaat langs elkaar heen.

In hoeverre dat dus driver afhankelijk is, en in hoeverre dat dus op die bus geimplementeerd moet worden voordat dat werkt, kan ik zo snel niet zien/vinden.

Als je er vanuit gaat dat je je Host heel dun houdt, en juist alleen maar PV kernels gaat gebruiken, hoef je je over security ook niet zo heel druk te maken denk ik. Er zit altijd wel een risico aan virtualisatie, en dat moet je ook gewoon voor lief nemen.

Ik heb persoonlijk ook niet zo'n probleem met de scurity, maar meer met drivers die roet in het eten gooien.

Denk aan de famous Hauppauge kaarten die tot de PCIe versies NIET werkten met meer dan 4GB geheugen.
Gewoonweg omdat de hardware zo brak gebouwd was dat het niet snapte als je er een DMA commando naartoe stuurde van > 4GB.

Stel dus dat je een PV guest maakt met 4GB geheugen, wie zegt dat dat blijft werken met zo'n Hauppauge kaart. Ik ben er een beetje huiverig voor dat op het moment dat die kaart dus krakt, mijn hele OS stuk gaat...

Als je al die risico's voor lief neemt (of heel grondig gaat testen) is Xen dus in theorie een prima oplossing.
Als jou hardware een acceptabele performance heeft en je hebt geen issues met PV kernels, *EN* je vind de lagere security prima, is Xen wat mij betreft een prima oplossing als ik het zo lees.

[FireDrunk]

Even terugkomen op mijn tests, gister een Windows 7 VM via NFS op de ZFS RDM gezet, dit ging in principe goed, alleen na 70% van de instalaltie kreeg ik 1 error op de MPT0 controller (Mijn VM maakt gebruik van de LSI Logic SAS controller.) Foutmelding was iets met een timeout, maar alles ging verder wel gewoon door in de installatie. Na de installatie geprobeerd de ZFS VM te rebooten, maar dat ging niet, die hing.
Na een harde reset een ZFS scrub gedaan, maar geen errors gevonden.

Beetje vreemd, maar het lijkt toch een software glitch geweest te zijn in de LSI driver, misschien eens kijken of die te updaten is.

[sloth]

Uit posts uit Het grote ZFS topic blijkt dat FreeBSD + ESXi + RDM + ZFS op dit moment geen stabiele opzet is.

Heeft iemand van jullie ervaring met een Solaris afgeleide als OpenIndiana als guest in ESXi, die disks doorkrijgt via RDM zonder passthrough (VT-D)?

[VorCha]

Ik denk dat ik dan voorlopig toch maar voor ZFS icm met ESXi en USB 3.0 ga proberen.

[Anoniem: 15758]

@sloth: mijn google-acties lijken erop te wijzen dat zijn specifieke probleem met 3TB disks (>2.0TiB) te maken heeft. Zie hiervoor: http://forums.freenas.org...ees-3TB-ESXi-5-RDM-as-0MB

Dat zijn nog andere problemen dan die met vt-d en MSI/MSI-X in combinatie met FreeBSD 9.

[FireDrunk]

Ik denk dat dat komt omdat een VMDK maar 2TB mag zijn. Er zal dus wel iets niet goed gaan in de host laag.
Je mag wel extenden (dus een spanned vDisk kan wel over meerdere VMDK's) maar de file zelf mag maar 2TB zijn volgens mij.

Er zal dus wel iets verkeerd gaan in die vertaalslag van host sata naar guest sata/sas.

[sloth]

FireDrunk schreef op zaterdag 28 juli 2012 @ 15:02:
Even terugkomen op mijn tests, gister een Windows 7 VM via NFS op de ZFS RDM gezet, dit ging in principe goed, alleen na 70% van de instalaltie kreeg ik 1 error op de MPT0 controller (Mijn VM maakt gebruik van de LSI Logic SAS controller.) Foutmelding was iets met een timeout, maar alles ging verder wel gewoon door in de installatie. Na de installatie geprobeerd de ZFS VM te rebooten, maar dat ging niet, die hing.
Na een harde reset een ZFS scrub gedaan, maar geen errors gevonden.

Beetje vreemd, maar het lijkt toch een software glitch geweest te zijn in de LSI driver, misschien eens kijken of die te updaten is.

Mogelijk kan dit een oplossing bieden?

quote: http://hardforum.com/showthread.php?t=1679233

Installing Freenas 8.0.x under ESX5i with the SAS2008 card passed through (VMDirectpath) produced the following errors during Freenas boot:

run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config mps_startup
run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config mps_startup

and it never gets past that stage.

To solve that problem:
Shut down the VM
Edit the Freenas VM Settings.
Detach the SAS Card.
Boot Freenas.

Edit the loader.conf
Add the following to it:

hw.pci.enable_msi="0" # Driver Interrupts problem SAS2008
hw.pci.enable_msix="0" # Driver Interrupts problem SAS2008

Shut down the VM
Edit the Freenas VM Settings.
Add the PassThrough SAS Card. (Your reserved memory should be the same value as the memory allocated to the VM (VMDirectpath requirement) otherwise it will not boot.
Boot Freenas.

Problem Solved!

Ook lees ik dat het toekennen van slechts 1 core het e.e.a. op kan lossen, of had je dat al getest?

[FireDrunk]

Dat MSI/MSI-X verhaal hebben we al toegepast. 1 vCPU kan ik nog proberen inderdaad.

[Anoniem: 15758]

run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config mps_startup

Deze melding krijg je met de OUDE 'mps' driver die nog experimental was; bekend probleem en vermeld in de manpage. De oude 'mps' driver die dit probleem heeft, zit in 9.0-RELEASE maar al snel daarna was in 9-STABLE de verbeterde 'mps' driver waar ook LSI aan gewerkt heeft. Die driver is nu 'af' en bovenstaand probleem zou niet mogen optreden. ZFSguru heeft al lang de nieuwe mps driver dus dat kan het probleem niet zijn lijkt me.

mpt = LSI 3Gbps controller (SAS1068E)
mps = LSI 6Gbpa controller (SAS2008)

[FireDrunk]

Zou er iets van een firmwarecheck in die driver zitten? Misschien is de virtuele firmware in de gevirtualiseerde LSI Controller van VMware wel een beetje oud...

[Pantagruel]

sloth schreef op dinsdag 31 juli 2012 @ 12:00:
Uit posts uit Het grote ZFS topic blijkt dat FreeBSD + ESXi + RDM + ZFS op dit moment geen stabiele opzet is.

Heeft iemand van jullie ervaring met een Solaris afgeleide als OpenIndiana als guest in ESXi, die disks doorkrijgt via RDM zonder passthrough (VT-D)?

Sorry voor t reanimeren van een oude thread

Deze avond een VM ingericht op basis van OpenIndiana,

code:

Pantagruel@OI-VM:~$ uname  -a
SunOS OI-VM 5.11 oi_151a7 i86pc i386 i86pc Solaris

en er Napp-It opgezet, gemak dient immers de mens .

2 stuks Samsung HD103 1TB's mbv RDM (vmkfstools -z etc), aan de VM gegeven en er een mirrored pool van gemaakt. Op dit moment ben ik bezig om er ca. 140 GB aan foto's op te zetten om de pool van data te voorzien. Daarna gaan we zien of de boel 'heel' blijft, op dit moment zijn er geen error meldingen.

[sloth]

Je hoeft je niet te excuseren hoor, bedankt voor de update
Hoe ziet je config er verder uit?
Ik ben erg benieuwd of het onder OpenIndiana wel kan. Deel zeker je ervaringen!

[ Voor 12% gewijzigd door sloth op 13-12-2012 00:29 ]

[Pantagruel]

sloth schreef op donderdag 13 december 2012 @ 00:15:
Je hoeft je niet te excuseren hoor, bedankt voor de update
Hoe ziet je config er verder uit?
Ik ben erg benieuwd of het onder OpenIndiana wel kan. Deel zeker je ervaringen!

De config:

#	Product	Prijs	Subtotaal
1	Intel Core i3 2120 Boxed	€ 103,95	€ 103,95
1	Asrock B75 Pro3-M	€ 57,90	€ 57,90
1	Corsair Vengeance CML32GX3M4A1600C10	€ 136,90	€ 136,90
1	Intel Postville X25-M SSDSA2MJ080G201 80GB	€ 99,90	€ 99,90
Bekijk collectie Importeer producten		Totaal	€ 398,65

Zitten in totaal 3 stuks 1 TB van Samsung 1. Een via RDM aan de Ubuntu download VM (sabnzb/sickbeard) geknoopt, en de andere twee dus aan de OI VM. Verder draaien er een management VM en een web/email VM.
Mocht de OI VM probleemloos werken dan zal uiteindelijk de losse 1 TB drive van de Ubuntu VM afgepakt worden en vervangen worden door een NFS/CIFS share afkomstig van de OI vm.

Add.
Voor de ZFS guru's onder ons, mocht er een manier zijn om versnelt fouten af te dwingen dan lees ik dat graag. Aangezien t een test VM is en er geen kritieke data op staat, steek ik hem graag een stok tussen de spaken.

[ Voor 4% gewijzigd door Pantagruel op 13-12-2012 10:48 ]

[RudolfR]

Ik detecteerde de problemen als ik druk aan't torrenten was.
(Transmission)

[FireDrunk]

tja, je kan inderdaad gewoon een dikke download openzetten.

Misschien is Bonnie++ flink draaien met een grote test size (1TB ofzo) ook wel een idee.

[Pantagruel]

FireDrunk schreef op donderdag 13 december 2012 @ 11:07:
tja, je kan inderdaad gewoon een dikke download openzetten.

Misschien is Bonnie++ flink draaien met een grote test size (1TB ofzo) ook wel een idee.

Tja, de 140 GiB kopieer actie is moeiteloos verwerkt, dus tot zover gaat t goed.

Ik zal Bonnie++ eens aan t werk zetten.

Update:

Wat bonnie++ runs van 16/32/64/128/250GB aan test data (5x repeat gezet) verder is de pool nog zo fris als t spreekwoordelijke hoentje en geheel vrij van fouten (scrub gaf ook geen error meldingen). Ziet er dus goed uit.

(Test van meer dan 250GB wilde niet omdat bonnie niet meer dan 252 files wilde maken, ik heb nog met de -n optie wat dingen getest, maar dat gaf geen soelaas)

Update na 2 maanden van gebruik:
Alles werkt nog naar behoren en de ZFS-pool is nog steeds foutloos (wekelijkse scrubs)

[ Voor 40% gewijzigd door Pantagruel op 14-02-2013 22:50 . Reden: 2 maanden follow-up ]