[Kaufberatung] Xeon Board - onboard SATA per vT-d durchreichen (ESXi)

HerrSchmitz

Enthusiast
Thread Starter
Mitglied seit
10.02.2010
Beiträge
95
Hallo Forum,

ich plane die Anschaffung eines kleinen stromsparenden homeserver samt Virtualisierungsmöglichkeit. Es soll ein FreeNAS (ZFS), debian (nginx mit owncload), Openvpn Server und ein Windows 7 Client drauf laufen (nichts aufwendiges). Die Hauptclients werden ein Desktop und ein Laptop die ihre Benutzernamen auf dem FreeNAS ablegen.

Frage 1: Als CPU soll ein Xeon -e3-1220l-v3 oder E300-1230l v3 eingesetzt werden. Das sollte doch bei der geringen Client Anzahl ausreichend sein oder?

Frage 2: Um die Hardware Kosten gering zu halten möchte ich auf einen zusätzlichen raid Controller verzichten. Daher stelle mir gerade die Frage, ob es Xeon Mainboards mit Sockel 1055 gibt, bei denen sich einzelne onboard s-ata controller an eine VM unter ESXi per VT-d durchreichen lassen.

Beste Grüße
HerrSchmitz
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Zu Frage 1: Ja. Auf die bekannten Argumente gegen eine VM Freenas auch hier im Forum darf ich verweisen.
Zu Frage 2: Einzelne "Controller"? Falls die Frage richtig formuliert ist, antworte ich mal mit "42". Ansonsten: Die meisten Boards haben genau einen (1!) SATA-Controller. Der "sollte" durchreichbar sein, schiebt dann aber auch ALLE Sata-Ports in die VM. Was wiederum für einen Host mit vier VMs ein Problem sein dürfte. Die Asrock-Boards haben häufig einen zusätzlichen Marvell-Chip drauf, der sich durchreichen lässt. Aber sinnvoll ist das insbesondere für FreeNAS eher nicht. Wenn eine VM Freenas einige HDDs managen soll, sollte eine getrennte PCIe-Karte in Betracht gezogen werden. Oder zwei getrennte Server.
 
Zu Frage 1: Ja. Auf die bekannten Argumente gegen eine VM Freenas auch hier im Forum darf ich verweisen.
Zu Frage 2: Einzelne "Controller"? Falls die Frage richtig formuliert ist, antworte ich mal mit "42". Ansonsten: Die meisten Boards haben genau einen (1!) SATA-Controller. Der "sollte" durchreichbar sein, schiebt dann aber auch ALLE Sata-Ports in die VM. Was wiederum für einen Host mit vier VMs ein Problem sein dürfte. Die Asrock-Boards haben häufig einen zusätzlichen Marvell-Chip drauf, der sich durchreichen lässt. Aber sinnvoll ist das insbesondere für FreeNAS eher nicht. Wenn eine VM Freenas einige HDDs managen soll, sollte eine getrennte PCIe-Karte in Betracht gezogen werden. Oder zwei getrennte Server.

Da ich FreeNAS in den letzten Jahren sehr zu schätzen gelernt habe, stand ich vor ähnlichen Überlegungen. Ich bin zum Schluss gekommen, dass ich FreeNAS nicht mehr in einer VM laufen lassen will und probiere es nun mit Proxmox auf dem ZFS, S.M.A.R.T.-Überwachung (und sonst nicht viel mehr) läuft. Das ganze SMB/NFS-Sharing läuft in einer VM, momentan "handkonfiguriert", aber ich wollte mal ausprobieren, ob ich nicht diese Turnkey-Fileserver-Appliance in einem Container zum laufen bekomme, dann steht man nicht ganz ohne Web-GUI da.

Bei der ganzen Durchreicherei von Festplatten in VMs hat Du das Problem, dass die HDs/SSDs dann exclusiv der VM zur Verfügung stehen und Du das FreeNAS-Storage dann nur über NFS, iSCSI oder SMB an andere VMs durchreichen kannst, das mag gehen, ist IMHO für einen Home-Server aber reichlich kompliziert und viel Overhead.
 
Schau dir mal das Supermicro X10SL7-F (MBD-X10SL7-F-O) Mainboard an.
Das hat einen onboard LSI SAS2308, den du auf IT Mode (Funktion als HBA, kein RAID) flashen und dann an eine Storage VM durchreichen kannst.
 
Zu Frage 1: Ja. Auf die bekannten Argumente gegen eine VM Freenas auch hier im Forum darf ich verweisen.

Hi,

ich hoffe, ich darf dazu mal eine Frage einbringen. Ich würde gern ebenfalls einen EXSI-Host aufsetzen mit einer FreeNAS VM wobei ich 4 HDDs (bzw. den IBM MegaRAID M1015 mit 4 HDDs) direkt durchreichen wollte. Was sind dabei die "bekannten Argumente dagegen"?
 
Zuletzt bearbeitet:
Unabhängig von FreeNAS,
der M5014 als Hardware Raid Controller taugt nicht für ZFS.
 
Ich will kein Raid fahren (Raid macht mehr Probleme als es löst). Der Controller (bzw. wie ich ja schon geschrieben haben, die Platten) werden 1:1 durchgereicht nur dafür ist der Controller da. Darüber hinaus wird der M1015 sogar explizit empfohlen auf der Kompatibilitätsliste bei Freenas.

Das sollte doch kein Problem darstellen, oder? Und wie sieht es mit meiner eigentlichen Frage aus? ;)
 
Zuletzt bearbeitet:
Nun ja

Kein Raid und kein ZFS - da kann man noch ruhig schlafen,
denn man erfährt von Plattenproblemen nichts oder erst wenn es zu spät ist.

Kein Raid und ZFS - nein danke
ZFS meldet jedes Problem sofort, kann es aber nicht reparieren - dafür braucht man Redundanz = Raid

Ein billiger IBM 1015/ LSI 9211/ LSI 9207 HBA - das ist was ZFS möchte -
und nicht ein Hardwareraid bei dem mit viel Glück ein Raid-0 mit einer Platte funktioniert
oder bei dem ein Hardware Raid angelegt wird, bei dem ZFS Fehler meldet, die es ebenfalls nicht reparieren kann.
 
Zuletzt bearbeitet:
Das durchreichen des onboard SATA Controller geht mit den wenigsten Boards. Und wenn, dann eher beim 2011er Sockel zu finden. Das war wenigstens früher so.

Aus folgendem Grund: man kann per vt-d nur ganze PCIe Brücken durchreichen. Beim 2011er Sockel ist dabei die Chance grösser, dass die betreffenden PCIe Lanes "frei" sind, bzw. nicht auch noch anderwertig gebraucht werden. Dasselbe gilt auch für andere Chipsatzhardware wie USB Controller oder NIC's. Ist auch noch ein wenig Glückssache dabei.

Ich verzichte ganz auf VT-d, obwohl meine X79 Hardware dazu in der Lage wäre. Und wenn ich ein Storagecontroller tatsächlich per VT-d durchreichen müsste/wollte, würd ich das mit einem dediziertem Controller machen. Und wenn ich das vor hätte, würde ich auf die HCL von vmware einen Blick werfen.

Was hält Dich davon ab, die Daten am Host in einer VMDK zu speichern? Sonst kannst Du ja direkt auf Blech bauen... Ist natürlich nur meine Meinung.
 
Die Gründe gegen Freenass@VM sind die gleichen wie bei allen VM als Fileserver: Zuverlässigkeit und Sicherheit gehen mehrere Stufen runter, da die VM zahlreiche neue potentielle Fehlerquellen addiert.
Ich hatte nur auf Freenas bezogen, weil es dazu umfangreiche Forendiskussionen gibt.
Als Beispiel: Die PCI(e)-Durchreichung ist in etlichen Bios-/Kernel-/Betriebssystemversionen buggy, inkl. bei meinem Dell-Profi-Server. Für eine VM "Sophos-UTM" könnte das heißen, die UTM stürzt ab, kein PC kann mehr ins Internet, VPN tot u.v.m.
Ein VM-Fileserver kann durch solche Fehler aber komplette HDDs/SSDs zerschießen, wenn sich im Schreibvorgang der Devicetreiber verabschiedet.
Nicht umsonst beziehen "professionelle" VM-Umgebungen immer den Speicherplatz von Hardware-SANs (vorzugsweise über FC, im small-Office über ISCSI).
Einen Fileserver zu virtualisieren sollte man sich jedenfalls auch im Home-Einsatz gut überlegen und eine Backupstrategie gleich mit...
 
Pass-through geht nicht mit beliebiger Hardware.

Es gibt aber Hardware z.B. Intel Xeon SuperMicro Boards mit LSI HBA wo das absolut problemlos läuft -
ich mach das seit über 6 Jahren so und habe das Konzept mit Solaris/OI ZFS damals aufgebracht -
anfangs mit heftiger Ablehnung vor allem im FreeNAS Forum - wo man das heute aber auch macht.

Die Zuverlässigkeit und Performance ist durchaus auf dem Niveau von Hardware Setups.
Und korrupte Dateisysteme sind bei ZFS und Passthrough genausowenig zu erwarten wie
direkt auf Hardware bzw. ohne ZFS genauso wahrscheinlich auf Hardware wie unter Pass-through.

Bis ESXi 5.5 gab es auch überhaupt kein Problem mit Sata Pass-through -
wobei der Normalfall natürlich Sata -> ESXi und SAS HBA -> ZFS ist.
Onboard Sata AHCI pass-through + Billig Sata Controller für ESXi ist nur bei Guenstig@home üblich -
geanau wie Sata pur + ESXi phsical RDM (Durchreichen einzelner Platten)
 
Zuletzt bearbeitet:
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh