VT-d ist nicht gleich VT. VT brauchst Du zwingend um 64 Bit Software laufen zu lassen.
nicht ganz
was du meinst ist VT-d... Und VT-x... Ersteres gibt es bei Intel meine ich nur, wenn die CPU auch VT-x unterstützt. Sprich kann die CPU VT-d, kann sie auch VT-x, man könnte VT-d wohl als Untermenge von VT-x bezeichnen.
Kann eine CPU aber beispielsweise VT-d nicht (im Fall von Intel wären das zum Beispiel die K Modelle, wenn ich nicht alles täuscht), sollte man aber dennoch drauf achten, das VT-x unterstützt wird. Denn wie du auch schon sagtest, ohne VT-x keine 64Bit VMs unter ESXi oder auch Hyper-V.
64Bit VMs gehen aber grundsätzlich dennoch, wenn die CPU 64Bit kann. Beispielsweise mit dem horn alten VMware Server 1 Punkt irgendwas... Zumindest war das mal so...
Was willst Du denn für ein FS? NTFS? Ich bin komplett auf VMFS umgestiegen. Einer sagte mal passend dazu: dann kannst Du ja gleich (wieder) auf Blech umsteigen. Allerdings kannst Du mit VMFS glaub ich nur 2 TByte grosse "Partitionen" (LUNs) machen. Ich habe zwar VT-d Unterstützung, aber durchreichen von Hardware wird allgemein auch nicht empfohlen und somit von mir noch nicht praktiziert.
Wenn Du also bei einer Installation von Windows Server auf Blech bleiben würdest, hättest Du mit deinem Fileserver auch einige Vorteile.
Die Frage nach dem Filesystem stellt sich beim ESXi ja aber gar nicht... Entweder du nutzt VMFS oder eben hast kein Storage
Bestenfalls wäre noch RDM zu nennen, aber auch bei RDM benötigt man wohl irgendwie noch ein Stückchen Datestore, wo die VMX Datei sowie diverse andere Konfig und Logfiles pro VM abgekippt werden können. Das gleiche gilt auch beim Durchreichen eines Controllers an eine VM.
Ansonsten empfohlen oder nicht ist da übrigens nicht das richtige Wort. Die Möglichkeit besteht grundsätzlich erstmal. Man erkauft sich damit aber ein paar gravierende Nachteile. Ob einen das dann tangiert oder ob man diese Nachteile in Kauf nehmen kann, muss jeder für sich selbst entscheiden.
PS: 2TB LUN Begrenzung war mal
Ab ESXi 5.0 gehen auch mehr... Wir haben auf der Arbeit teils 3-6TB LUNs an internen Storage in einigen Servern, die als Stand Alone Geräte teils beim Kunden im RZ tuckern.
Wichtig ist, VMFS Version 5 muss als Filesystem sein. Ebenso wichtig ist, man kann zwar VMFS3 Volumes von älteren Installationen konvertieren, aber das Resultat entspricht nicht vollumfänglich dem einer frischen VMFS5 Formation. Nämlich bleibt die Blockgröße des alten Volumes bestehen. Frisch formatiert hat VMFS5 beispielsweise immer 1MB Blocksize. Wärend große Volumes je nach benötigtem Platz am Stück pro VMDK Datei auch mal mit 8MB aufgefahren sind.
Sprich wenn man kann, sollte man hier klar frisch die Volumes Formatieren.
Was aber aktuell, wenn mich nicht alles täuscht eben nicht geht, sind VMDK Files größer 2TB. Das heist, pro virtuelle HDD ist das Limit nach wie vor bei 2TB.
Man kann aber natürlich der VM mehrere dieser 2TB VMDKs zuweisen. Und diese dann in der VM selbst wieder zusammen packen. Macht sich je nach verwendetem Zusammensetzverfahren auch Speedtechnisch nicht bemerkbar. Beispielsweise JDOB mit dynamischen Datenträgern unter Windows.
Ob der Fileserver nun direkt auf der Hardware, oder in einer VM rennt, ist dabei auch nichtmal wirklich ein Problem.
Zumindest bleibt als einziger Vorteil, das man den Platz des Storages komplett voll fahren kann, wärend in einer VM etwas Luft auf dem Storage einkalkuliert werden sollte.
Besser noch, man hat sogar einige Vorteile. Beispielsweise kann man via Snapshots direkt die ganze VM schnell und effizient wegsichern. Ohne dabei die Files native vom Fileserver saugen zu müssen. Je nach Anzahl und durschnittsgröße geht das nämlich extrem langsam.
