Fermion schreef op woensdag 22 oktober 2014 @ 12:18:
[...]
Ik zou er nog op terug komen (weinig tijd gehad) wanneer ik ZFS op mijn ESXI aan de praat heb gekregen, het werkt allemaal, pass-through van de SATA, maar alleen in ESXI 5.1. In ESXI 5.5 werkt SATA pass-through niet meer (ergens gelezen dat dit bij design is, idioot voor woorden).
Ik weet niet wat je hier nou allemaal zegt, maar SATA passthrough heeft nooit bestaan... Er is RDM (het doorgeven van lokale LUN's (in veel gevallen iSCSI of FibreChannel LUn's), wat misbruikt kan worden om lokale schijven door te geven. En er is VT-d, wat een heel PCI Express device door kan geven. Waar jij waarschijnlijk op doelt is het doorgeven van de Onboard SATA controller door middel van VT-d. Dat ligt helemaal niet aan ESXi (5.1 of 5.5), het heeft te maken met hoe het moederbord werkt met zo'n onboard controller... Bij sommige borden is de IOMMU (de generieke naam voor VT-d) anders ingericht dan bij anderen. En vooral bij de nieuwste Intel AHCI controller is dat nogal een probleem. Dit heeft weinig met de controller an sich te maken, en ook weinig met de ESXi versie. Hooguit dat ESXi wat voorzichtiger is, met het doorgeven, om je hele server niet om zeep te helpen. ESXi is niet kieskeurig qua devices als het gaat om VT-d. *ALLES* waarvan je moederbord *ZEGT* dat het doorgegeven kan worden, staat ESXi je toe om door te geven.
Dus als ESXi 5.5 wel een device toestaat om door te geven, en ESXi 5.1 niet (of andersom), heeft dat meer te maken met de manier waarom het moederbord ACPI praat met ESXi. Bedenk HEEL GOED, dat we hier (bijna) allemaal met white-box hardware werken, en al die hardware in geen enkel geval officieel gesupport is door ESXi... Als jij met een gesupporte machine aankomt, en tegen VMware zegt, mijn VT-d werkt niet goed, helpen ze je direct, en krijg je een patch....
Dus keihard roepen dat VMware het allemaal niet goed doet, is een beetje overtrokken...
ESXI 5.5 heb ik dus niet meer nodig, dacht eerst hem wel nodig te hebben voor het aanmaken van de 7.2TB VMDK file, maar omdat NAS4Free in ESXI nu direct de drives aanstuurt, ben ik in ESXI 5.1 niet gebonden aan de 2TB VMDK file limit (let wel, voor NAS4Free wordt dus geen VMDK meer gebruikt!)
Wat je hier allemaal verteld, is mij een raadsel, maar volgens mij schreeuw je heel hard wat je eigen configuratie is... Leuk, maar op deze manier hebben we er niet zo veel aan...
Ik adviseer binnen ESXI geen gebruik te maken van VMDK als storage voor een NAS data storage oplossing (na veel lezen en wijze adviezen, ben ik voor ZFS gegaan!). Mijn voorkeur is NAS4Free (omdat de interface mij bevalt en natuurlijk FreebBSD variant).
Dat is zeker waar, maar ook al heel vaak gezegd.
Mijn ervaring is dat ESXI onderwater meer doet dan wenselijk is, zoals zelf snapshots maken terwijl ik daar niet om vroeg (althans de aangemaakte files leken op snapshots want de files waren incremental tov de origineel).
Dat kan helemaal niet, ESXi kan helemaal niet zomaar snapshots maken, dat doet altijd externe software (vSphere Client, vCenter, backup software, of iets in die trant).
Ook adviseer ik wanneer je een VMDK aanmaakt, je altijd voor de optie gaat: Thick Provision Eager Zeroed. Mijn uitgangspunt is niet voor een beter performance, maar het geeft je een kans een restore te doen bij een disk crash (of het terug halen van een per ongeluk gewiste file).
Leuk idee, maar adviseer liever dat mensen backups maken. Het is een drogreden om dit te noemen omdat je dan kan recoveren bij een kapotte disk... Disks sterven veel vaker ineens, en zijn helemaal niet meer leesbaar, dus recovery is dan sowieso al (bijna) niet meer mogelijk.)
Bij Thin Provision kan je nooit meer je VMDK terughalen.
Onzin, het is alleen moeilijker.
Let wel, om pass-through mogelijk te maken moet je CPU en je Moederbord dit ondersteunen!!
Klopt, maar misschien nog weer meer,
Je BIOS / UEFI.
edit: Met de pass-through is SMART ook door NAS4Free uit te lezen, die informatie wordt weer gebruikt wordt door ZFS.
ZFS doet niets met SMART, dat is een broodje-aap verhaal.
Even niets...