ESX / ESXi - Hilfethread

Viele von euch haben ESXI in Verbindung mit Freenas laufen. Ich besitze einen Dell T20 und würde dort gerne die gleiche Konstellation laufen lassen. 4*4TB HDDs und 2*500gb SSDs werden per passthrough an Freenas durchgereicht. Weitere VMs wie Windows 10 und Linux Server sollen auf die 2*500gb SSDs installiert werden. NUn ist die Frage wie reiche ich die 2*500gb SSDs wieder an ESXI für die VMs zurück um die maximale Geschwindigkeit zu erreichen? Darüber hinaus möchte ich in der LInux VM Dienste wie JDownloader, Syncthing usw. laufen lassen. Solche DIenste könnte ich zwar auch direkt in Freenas integrieren. Allerdings möchte ich gerne die Datenverwaltung (Freenas) von den Diensten trennen. DIe Frage ist dann auch wie Linux Server auf die 4*4TB HDDs von Freenas zugreift um seine Daten dort ab zu legen. Hat ESXI dafür kein internes System um Freigaben an die VMs durch zu reichen?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Geht per NFS-Share oder iSCSI. Das ist innerhalb der Maschine ja ein virtuelles Netz und damit vom Durchsatz nur von der CPU limitiert, idealerweise nutzt man dafür in den VMs die VMXNET3-Nic, nicht die E1000. Dieses Setup ist für Homelabs performant genug; sequentiell geht bei mir so max. 2,2 bis 2,3 GiB/s drüber und auch die Latenzen sollten kein Problem darstellen, solange man keine großen Multiuser-Oracle-DBs drüber laufen lässt (dürfte daheim wohl kaum vorkommen :) )

Sprich. ESXI aufs Metall installieren, eine Storage-VM einrichten für FreeNAS/Xigmanas einrichten, die vorgesehene Datenträger an einen LSI-/Broadcom SAS-Controller hängen und den Controller dann per vt-d Passthrough an die Storage-VM weiterreichen.
Die ZFS-Pools, Datasets und Volumens werden dann ausschliesslich in der VM bereitgestellt und auch administriert. Von dort dann NFS/iSCSI-Freigabe einrichten, die dann wieder im ESXI als Datastore eingehängt werden können.

Du brauchst dafür ein Bootmedium für ESXI (z.B. USB-Stick oder aber eine kleine SSD), eine kleine SSD als Datastore für die Storage-VM (zum Startzeitpunkt kennt ESXI ja die NFS-Shares noch nicht und irgendwo muss die Storage-VM ja drauf liegen) und als Goldstandard einen SAS-HBA mit SAS2008, SAS2308 oder SAS3008 Chipsatz mit Firmware im IT-Modus (=HBA only), damit ZFS die Speichermedien ohne Hard- oder Software-Zwischenschicht ansprechen kann. Hardware-Raid ist da ein "no no".

Die Storage-VM könnte man theoretisch auch auf die Boot-SSD mit dem ESXI legen, aber hat dann ggf. Stress, wenn man ESXI neu installieren muss; die Datastorage-Partitions sind nämlich da weg. Hat man da 2 Devices, bleibt der Datastore mit der Storage-VM erhalten und kann in eine potentielle spätere Neuinstallation einfach wieder eingehängt werden.

Btw, diese 2. SSD für den Basis-Datastore kann auch eine Intel Optane 900p sein. Die Storage-VM braucht nur sehr wenig Platz, den Rest kann man dann als Virtualdisk in die Storage-VM ggf. als ZFS-Slog oder L2Arc geben. Normal ist es absolut nicht empfohlen, VMDKs als ZFS-Device zu verwenden, aber die 900p ist schnell genug und da sie keinen Ram-Cache braucht auch relativ sicher.

Wichtig: NFS läuft über sychnrone Schreibzugriffe. Entweder verbietet man das dann auf dem ZFS-Dataset (set sync=disabled, damit hebelt man aber enorm viel Sicherheit von ZFS wieder aus), oder man braucht relativ schnell ein Slog-Device oder Datacenter-SSDs da es sonst schnell sehr langsam wird, wenn man ständig schreibt. Selbst gute Consumer-SSDs wie eine 850pro gehen da schnell ein bzgl. Durchsatz und Latenz.
Meine Meinung: Zum Lernen und Rumprobieren ist sync=disabled IMO ok, nutzt man die Kiste real mit Daten die man im Ernstfall nicht verlieren will, sollte man das nicht tun.

Was Du ab ESXI 6.7 vergessen kannst, sind Onboard-Satacontroller als Passthrough-Device in eine VM durchzureichen. Klappt nicht mehr, das geht derzeit nur bis ESXI 6.5. War glaub ich nie ein offizielles Feature von Vmware.
 
Zuletzt bearbeitet:
Danke für die ausführliche Rückmeldung. Bedeutet wenn ich in der Freenas-VM und bspw. Ubuntu-VM VMXNET3 auswähle und Ubuntu auf das Storage von Freenas zugreift, dann läuft das nicht über die Netzwerkkarte sondern intern? Ich kann aber gleichzeitig mit VMXNET3 über die Netzwerkkarte ins normale Netzwerk?

Ich habe eine kleine SSD an einen onboard Sats Controller angeschlossen und darauf ESXI und anschließend auch gleich die Freenas VM installiert. Ich habe keine Lust noch eine SSD für Freenas zu verschwenden oder einen langsamen USB-Stick zu nehmen. So bootet alles schön schnell. Wenn die SSD defekt ist oder ESXI einen Fehler hat und ich neu installieren muss ist Freenas auch weg das ist richtig. Aber wenn ich mir die Freenas Konfiguration wegspeicher ist das eigentlich recht schnell wiederhergestellt. Ich habe einen DELL HP Perc H310 im IT-Mode wo dann die HDDs und SSDs an Freenas durchgereicht werden.

Ich habe auch bereits gelesen, dass man bei NFS sync=disabled setzen muss und dadurch Sicherheit flöten geht. Aber der Server ist an einer USV angeschlossen und solange er vor dem Stromverlust sauber heruntergefahren wird ist doch eigentlich alles gut oder?
 
Eine USV hilft dann schonmal, das Risiko dass eine Serverkomponente (Mainboard oder NT z.B.) ausfällt bleibt dann halt. Ich hab sync an und es mit der 900p als Slog gelöst.

Bzgl. Nics: Korrekt, dann läuft das innerhalb des VirtualSwitch. Und Du kannst natürlich von den VMs dann auch ins "normale" Lan. Musst halt die IP-Adressen entsprechend einstellen, dann is des kein Problem.
Oder kannst natürlich auch mehrere VNics vergeben mit getrennten IP-Adressbereichen. Sowas geht alles.
 
Zuletzt bearbeitet:
Ich habe eine kleine SSD an einen onboard Sats Controller angeschlossen und darauf ESXI und anschließend auch gleich die Freenas VM installiert. Ich habe keine Lust noch eine SSD für Freenas zu verschwenden oder einen langsamen USB-Stick zu nehmen.

Ich habe seit jeher vSphere auf einem USB Stick, und der läuft seit Jahren durch. Kann sein, dass Dein Server 5% schneller bootet mit Deiner Methode, dafür bist Du aber wesentlich unflexibler mit vSphere und dem Filer auf einer Platte. Würd ich mir nicht antun wollen.
 
Man kann sich auch beim Raid einen kleinen Bereich für den ESXi reservieren.
 
@Boy2006
Ich habe mal gelesen, das auf dem ESXI Datenträger keine VMS installiert werden sollten... auf dem RAID Volumen geht dies ja nicht❓ Ausser ich erstelle aufwendig auf dem RAID Volumen eine Partition ESXI... oder verstehe ich dich falsch ?
Ich habe ESXI bis jetzt auf einer USB SSD instaliere die sich im Server befinden.
 
Ich habe mal gelesen, das auf dem ESXI Datenträger keine VMS installiert werden sollten... auf dem RAID Volumen geht dies ja nicht❓ Ausser ich erstelle aufwendig auf dem RAID Volumen eine Partition ESXI... oder verstehe ich dich falsch ?
Ich habe ESXI bis jetzt auf einer USB SSD instaliere die sich im Server befinden.

Kommt drauf an in welchem Kontext die Aussage getroffen wird - VMs auf nem USB Stick, ner CF-Card oder SD-Card ist nicht unbedingt zu empfehlen.
Wenn du aber direkt auf HDD/SSD installierst oder eben ein Raid in Hardware baust und den ESXi dort auf das Volume installierst, legt der dir auch völlig von allein einen lokalen Datastore an.

Was man auch machen kann ist eben, wenn es ein anständiger Raidcontroller ist, kann dieser idR verschiedene Volumes anlegen und dem OS sicherbar machen. So kannst du dann ein keine Ahnung, 8GB Volume für die ESXi Install anlegen und den Rest als Datastore. Ich nutze bspw. diese Möglichkeiten um bei meinen Veeam Backup Servern die Win Server Install auf ein 100GB Systemvolume zu installieren ohne dass du da groß UEFI Boot brauchst, weil die Bootplatte >2TB ist usw. -> beim ESXi ist das aber (meist) Wumpe.
 
Ich habe seit jeher vSphere auf einem USB Stick, und der läuft seit Jahren durch. Kann sein, dass Dein Server 5% schneller bootet mit Deiner Methode, dafür bist Du aber wesentlich unflexibler mit vSphere und dem Filer auf einer Platte. Würd ich mir nicht antun wollen.

Ich nehme eigentlich immer eine SSD Platte (Intel Datacenter) für ESXi und die Storage VM. Beim ESXi Update ist das unkritisch und alle anderen VMs liegen eh auf dem separaten (ZFS) Storage. Worst Case ist ohnehin ESXi neu installieren und Storage VM neu bereitstellen, dann VMs ins Inventory importieren - ca 30 Minuten Arbeit ohne allzuviel mitzudenken.
 
Worst Case ist ohnehin ESXi neu installieren und Storage VM neu bereitstellen, dann VMs ins Inventory importieren - ca 30 Minuten Arbeit ohne allzuviel mitzudenken.

Ich habe 11 vSwitches, und diverse vNIC's pro VM (z.T. 4-6 Stück). Deshalb würde ich gerne darauf verzichten, vSphere neu einrichten zu müssen. Bin gerade dran auf meinem neuen Server, da habe ich 4 Seiten MAC Adressen, die wieder an den ensprechenden vSwitch wollen.
 
Gut gebrüllt, Löwe :wink:

Hätte ich schon vor dem Plattform Wechsel machen sollen. Aber egal, der grosse Teil läuft wieder. Hatte eben dummerweise an der vSphere Konsole das Netzwerk zurück gesetzt, weil die Reihenfolge der NIC's nicht mehr gepasst hat. Das vSphere dann gleich alle vSwitches zurück setzt, damit hatte ich nicht gerechnet.

Wenn ich dann alles wieder fertig eingerichtet habe, werd ich den Stick dann sichern. Fürs nächste Mal.

Auf jeden Fall ist da bei mir nix "in 30 Minuten" für vSphere, Filer zurücksichern und einhängen der VM's. Dafür werd ich wohl noch einige Zeit brauchen. Habe auch noch andere Hobbys.
 
Ich habe 11 vSwitches, und diverse vNIC's pro VM (z.T. 4-6 Stück). Deshalb würde ich gerne darauf verzichten, vSphere neu einrichten zu müssen. Bin gerade dran auf meinem neuen Server, da habe ich 4 Seiten MAC Adressen, die wieder an den ensprechenden vSwitch wollen.

11 vSwitche? - Respekt... ist das nen Firewallcluster ?... - nur so aus Interesse.
Ich komm mit 4 vSwitches und am Host mit 4NICs + 10G SFP+ ganz gut hin o_O
 
Läuft unter anderem eine Spielzeuganwendung drauf:

Enigmabox virtualisiert (Seite 4 und 5 ist das Netzwerk)

Hatte den VPN Gateway mal auf verschiedenen Typ 1&2 Hypervisoren virtualisiert und getestet. Paravirtuelle Experimente habe ich auch noch gemacht dazu, da sind dann noch diverse vmnet dazu gekommen. Mittlerweile hab ich da etwas umgebaut, aber die beiden Endians habe ich wegen dem Traffic Monitoring von der Enigmabox gelassen.

99% der Adressen im Netzwerk werden per MAC und DHCP bezogen.

Im Moment habe ich 5 NIC's plus IPMI im Einsatz, eine NIC ist noch frei. Bin halt total der Netzwerk Messie :p
 
Zuletzt bearbeitet:
Kenn ich. :d Betreibe aus Faulheit auch 3 physische Netze und müsste mir eigentlich „nur“ mal Gedanken machen, wie es einfacher/besser geht. Gut, und diese Gedanken dann auch noch umsetzen...
 
Blöde frage! Aktuell Server Boards haben (zum glück) noch PCI drauf. Unterstützt das der ESXi?
 
Moin, bin ich blind oder gibt es unter 6.7 nicht mehr die Möglichkeit VM´s in Ordner/Gruppen zu unterteilen?
Mit 6.0 gab es meine ich doch die Möglichkeit, oder?
 
Das geht nicht mehr, weil der Client dies nicht unterstützt. Das wird bemängelt, seit der native Windows-Client sukzessive durch den HTML Client ausrangiert wurde. Keine Ahnung, ob das mal wieder kommen wird. Ich fänd es auch praktisch.

Zitat von ESXI Embedded Host Client

"What's missing?

The Embedded Host Client is currently undergoing development. We are working hard to bring the functionality level to that of the vSphere Client, but we're not there yet. Here's what we know is missing:

Resource pool management
Comprehensive performance chart UI with access to all performance counters
Exporting performance counter data to Excel/CSV
Multi-NIC vMotion configuration
Deploying VMs from a URL
Exporting VMs to an OVA"
 
Zuletzt bearbeitet:
Danke Dir. Schade. Wo es noch ging hab ich es nicht gebraucht, nun wäre es praktisch :-)
 
Habe ich jetzt nicht verstanden, was du machen willst? Ich kann Ordner anlegen und VMs sortieren wie ich lustig bin. Oder meinst du etwas grundlegend anderes?

2018-09-03 13_57_58-Window.png
 
Aber Du kannst keinen Ressourcenpool anlegen, oder?
Weil in nem Pool kann man ja festlegen, wieviel Leistung die darin enthaltenen VMs max. nutzen dürfen... ;)
 
@Fusseltuch: Das ist ein anderer Client? Nicht der mit ESXI ausgelieferte? Ist der auch kostenlos für Homeuser?
 
Der VSphere Client ist das alte Windows-GUI, das nicht mehr alle aktuellen ESXi Features unterstützt und deren Download immer schwieriger zu finden ist. War free, ist aber auch keine Lösung mit großer Zukunft..
 
Zuletzt bearbeitet:
Danke Elmarino. Ich habe den nativen Client ewig nicht mehr gesehen, so "modern" hatte ich den nicht in Erinnerung. Die Strategie ist offensichtlich hin zu embedded HTML5 client.
 
Das ist die HTML5 Weboberfläche der VMware vCenter Appliance. Nix spezielles und auch kein Fremdtool... Muss aber, wenn ich mich recht erinnere, zusätzlich lizenziert werden. Kostenfrei gibt's die Appliance nicht.

Ressourcenpool muss ich morgen mal schauen, das haben wir nicht im Einsatz.
 
Zuletzt bearbeitet:
Aha, die heisst also genau so? Naja, VM-Ware hat die Leute schon immer gerne mit konfusen Produktbezeichnungen und Lizenzen verwirrt..
 
Moin, das was du suchst ist der vCenter Server. Kostet je nach Lizenz zwischen 600€ und 10000€.

Die Freeware ala Esxi ohne vCenter Anbindung unterstützen dies seit wegfall des vSphere Windows Clients nicht mehr. Der Flash Client ist ein bisschen reduziert um unnötige Funktionen. Bei 40Vms sehe ich die Funktion sinnvoll aber nicht bei einer Handvoll Vms. Du kannst den vCenter Server auch 60 Tage testen oder mal dort reinschauen VMUG Advantage


Gruß Niklas
 
Ja, vCenter Server, ich kam nicht auf den Namen... :wall: Naja wir setzen's im Unternehmen ein, da ist das durchaus sinnvoll. Sind halt ein paar mehr VMs als man zu Hause haben würde.
 
Wenn nur der Web-Client mal endlich weniger als zwei Minuten brauchen würde um nur den Login zu zeigen!
Gibt's da immer noch keine Lösung für?
 
Host Client oder Web Client? Ich nutze den Host Client und habe das Problem nicht.

6.5.0 Update 1 (Build 7967591).
 
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