ESX / ESXi - Hilfethread

besterino schrieb:
Mal 'ne dumme Frage: ich habe am Wochenende ein wenig mit meinem System herumgespielt und jetzt verabschiedet sich der ESXi nach einiger Zeit (10 Minuten oder auch 2 Stunden) mit einem hübschen Purple Screen.

Was habe ich gemacht: im Prinzip habe ich nur einen vorhandenen SAS-HBA (Dell crossflashed H310) physisch herausgenommen und einen aktuellen Broadcom HBA (9305-24i bzw. 3224) in den gleichen Slot eingesetzt, den auf Passthrough gestellt. Weil das nicht wie gewünscht funktionierte, hab ich dann die Kiste physisch wieder zurückgebaut. Ich habe jeweils NICHT vor dem Wechsel Passthrough deaktiviert oder sonstige Konfigurationen in ESXi geändert.

Davor lief das System monatelang unauffällig (jaja, ... "never change"...). Einen Hardware-defekt würde ich eigentlich gerne ausschließen, habe ja nur an einem Steckplatz gefummelt. Memtest lief auch ca. 2-3 Stunden (64GB RAM).

In der /etc/vmware/esx.conf hab ich jetzt folgende Einträge:

Code: 
/device/00000:179:00.1/vendor = "10de"
/device/00000:179:00.1/device = "fb9"
/device/00000:179:00.1/owner = "passthru"
/device/00000:180:00.1/vmkname = "vmnic3"
/device/00000:179:00.0/owner = "passthru"
/device/00000:179:00.0/device = "1cb3"
/device/00000:179:00.0/vendor = "10de"
/device/00000:026:00.1/vmkname = "vmnic1"
/device/00000:026:00.0/vmkname = "vmnic0"
/device/00000:001:00.0/vendor = "1912"
/device/00000:001:00.0/device = "14"
/device/00000:001:00.0/owner = "passthru"
/device/00000:023:00.0/vmkname = "vmhba2"
/device/00000:023:00.0/vendor = "1000"
/device/00000:023:00.0/device = "72"
/device/00000:023:00.0/owner = "passthru"
/device/00000:000:17.5/vmkname = "vmhba0"
/device/00000:000:23.0/vmkname = "vmhba1"
/device/00000:180:00.0/vmkname = "vmnic2"
/device/00000:004:00.0/vmkname = "vmhba4"

So sieht die passthrough-Konfig in der Weboberfläche aus:
Anhang anzeigen 429842


Messerscharf kombiniert mit der passthrough.map heisst das für mich:

1.
Die Geräte an ...179:00... vom Vendor "10de" sind die Nvidia Quadro P400.

2.
026, und 180 sind auch logisch, das sind die 4 NICs (2x Onboard und 2x mit X540-T2).

3.
An ...001:00... sitzt die USB3-Steckkarte.

4.
Was mich irritiert: ich habe offenbar 4 HBAs, nämlich an 000 (HBA 0+1), 004 (HBA4) und 023 (HBA3) - von denen nur der vmhba2 als "passthru" markiert ist. Der HBA sitzt aber angeblich auf 0000:17:00.0 bzw. 0000:16:00.0 (Parent).

Der Host verabschiedet sich bisher nur in den Purple Screen, wenn (mindestens) eine der VMs mit Passthrough-Geräten läuft. Dabei himmelt es den Host auch, wenn nur die Windows-VM mit der durchgereichten Graka/USB-Karte läuft, zu der ich ja gar keine Veränderungen hardwareseitig vorgenommen hatte.

Hatte sowas (ähnliches) schon jemand / ist da irgendetwas durcheinander geraten? Was kann ich noch tun, um dem Fehler auf die Spur zu kommen (oder muss ich den Host neu aufsetzen - nervig aber machbar)?

Danke vorab für sachdienliche Hinweise!
Zum Vergrößern anklicken....

Ist das noch 6.0? Das hatte ja ne Ordentliche Palette an Purple-Screen Fehler... Vielleicht bist du ja von einem Bug getroffen.

was sagen vmkernel und weitere Logs?
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Hier hatte Mal jemand etwas zur Skalierung von vielen VMs auf wenigen Kernen vs vielen Kernen und dem damit verbundenen Overhead wenn die VMs sich Kerne Teilen geschrieben.
Hat den Post noch jemand an der Hand oder weiß wie dieser Overhead heißt ?
 
Ich habe am Wochenende mal länger damit zugebracht meinen MicroServer (1265L und 8 gb Ram) samt ESXI 6.5 hp u1 Image zu bestücken.

EDIT: Habe mein Problem hier gesondert beschrieben. Wäre für Hilfe dankbar.
 
Zuletzt bearbeitet:
Ist das RAID denn healthy? Wenn bei dem Reboot die VM nicht heruntergefahren war und aktuell ein Rebuild läuft, wäre das vielleicht eine Erklärung.
 
Hallo, hab mal eine Frage, da ich derzeit am überlegen bin, meinen DELL T20 etwas umzukonfigurieren.

Meine derzeitige Config:

- ESXi 6.0 auf USB-Stick
- SSD am internen Controller mit folgenden VMs:
--- 1x Win10
--- 3x Debian/Ubuntu mit unterschiedlichen Diensten
--- 1x FreeNAS

dazu ein an FreeNAS durchgereichter SATA-Controler mit 2x HDDs im ZFS Software Raid1 und 1x HDD mit ZFS für Sat-Aufnahmen

Aktuell liegen die VMs also "ungeschützt" (Backups mittels Veeam sind natürlich vorhanden) auf der eizelnen SSD.


Einzige Möglichkeit, die VMs auch etwas "sicherer" zu bekommen, wäre wohl dann, diese auf ein NFS-Share vom FreeNAS zu installieren. Ich könnte ja noch eine zweite SSD dazupacken und dann auch dort ein Raid1 anlegen.



Aber wie verhält sich das System dann, wenn ich z.B. den ESXi Host herunterfahre oder FreeNAS ohne vorheriges beenden der VMs neustarte?

Und muss ich dann in den automatischen VM-Start-Settings z.B. eintragen, dass die VMs auf dem NFS Share erst nach 1 Minute oder was weiß ich automatisch hochfahren sollen, damit dann das NFS Share auch sicher vorhanden ist?
 
Bib schrieb:
Aber wie verhält sich das System dann, wenn ich z.B. den ESXi Host herunterfahre oder FreeNAS ohne vorheriges beenden der VMs neustarte?

Und muss ich dann in den automatischen VM-Start-Settings z.B. eintragen, dass die VMs auf dem NFS Share erst nach 1 Minute oder was weiß ich automatisch hochfahren sollen, damit dann das NFS Share auch sicher vorhanden ist?
Zum Vergrößern anklicken....

Genau so. In den Autostart-Einstellungen die Parameter für Autostart / Herunterfahren entsprechend setzen. Erstens NAS-VM, dann die restlichen VMs. Ich habe betreffs Verzögerungen alles im Standard belassen, Ausnahme NAS-VM. Der gebe ich beim Start und Beenden 120 Sekunden.
 
Und wenn ich z.B. ein FreeNAS Update einspiele und dann die VM reboote, ohne die anderen VMs herunterzufahren?

Werden die laufenden VMs dann eingefroren oder bekomme ich dann beim erneuten starten Probleme wegen Dateninkonsistenz usw?


-------------------

Aktuell z.B. habe ich auf einer Debian-VM Openhab für mein Smarthome laufen. Bevor ich dort ein Update einspiele, mach ich unter ESXi einen Snapshot, dann update, wenn alles läuft ok, falls nicht, dann Snapshot zurück. Eine Sache von ein paar Minuten.

Das könnte ich dann auch innerhalb FreeNAS mit ZFS erledigen, oder? Bzw. müsste ich das überhaupt noch manuell machen? Sind Snapshots in ZFS nicht schon von Haus aus integriert?
 
Dann musst Du die VMs, die auf dem NAS gespeichert sind, vorher runter fahren. Sonst droht Datenverlust. So mache ich es zumindest :) ... scheint mir logisch, da ja nicht der HOST selbst runter gefahren wird, sondern selektive VMs.
 
Noch eine weitere Frage:

Ich habe derzeit die SSD ja direkt am internen Controller für die VMs und an der durchgereichten 4-fach-Sata-Karte hängen 3 HDDs.

Wenn ich jetzt mitels der SATA-Karte 1x Raid1 aus 2 HDDs und 1x Raid1 aus 2 SSDs mache, dann müsste ich die zusätzliche einzelne HDD an den internen Controller hängen, weil am 4-fach SATA kein Platz mehr ist.

Auf dieser HDD sollen nur SAT-Aufnahmen von den diversen SAT-Recievern im Haus landen und ein wenig Musik (Hörspiele für die Kinder) liegen da drauf, sonst nichts.


Wie binde ich diese HDD dann am besten in mein System mit ein? RDM oder einfach unter ESXi einen Datastore erstellen und diesen an FreeNAS weiterreichen?
 
Ich habe einen Server mit ESXi 6.5 und lediglich einem Netzwerk Interface. Auch vorübergehend, kann ich kein zweites Interface dran machen, auch kein USB o.ä.
Nun will ich diese einzige NIC per Passthrough an eine Router VM durchreichen. Sobald ich das Host Passthrough aktiviere, muss ich ja den Server rebooten ehe ich weitere Konfigurationen vornehmen kann.
Nach dem Reboot habe ich kein Webinterface mehr, weil der Server ja nicht mehr netzwerktechnisch erreichbar ist. Und auch in die Konsole der Router VM komme ich nicht, um die zu konfigurieren.

Die esxcli Kommandos sind eher rudimentärer Natur, z.B. das Passthrough aktivieren scheint darüber überhaupt nicht möglich zu sein. Gibt es eine Art Leitfaden für diese Art der Konfiguration? Ich habe non Zugang zur ESXi Konsole, mehr aber nicht.
Als Notlösung, wenn meine Konfiguration nicht hinhaut, kann ich nur das passthru aus der esx.conf rausnehmen und neu booten. Aber so richtig das gelbe vom Ei finde ich das nicht.
 
wie soll das gehen, ohne NIC nen ESXi?
Wozu überhaupt den Ast auf dem Sitzt absägen? - und warum braucht die Router-VM physisch diese NIC?

Was hast Du den "außenrum" gebastelt, damit das im Falle von NIC physisch in der Router-VM überhaupt wieder funtzt?
 
Meine Idee wäre, die NIC an die Router VM durchzureichen. Dann einen vSwitch zwischen ESXi Management Interface und Router VM. So, dass ich auf der Router VM natten und filtern kann.

An außenrumgebastel habe ich noch gar nichts, vielleicht stelle ich mir das Ganze etwas zu einfach vor. Hätte ich nach dem Passthrough eine vernünftige Konfigurationsmöglichkeit, (d.h. die ESXi WebGUI oder eine umfassende Doku zu den CLI Optionen), dann sollte das doch eigentlich kein Problem sein, oder?
 
Ich glaube, Du hast konfetti nicht verstanden: wenn Du die NIC an die Router-VM durchreichst, ist die nicht mehr für das Management des ESXi verfügbar, somit gibt es keine Möglichkeit, an die WebGUI oder per CLI an die ESXi-Konfiguration zu kommen, um ggf. die virtuellen Switches anzupassen. Aus, Ende, Vorbei.

Wenn Du eine Router-VM hast und Passthrough einer NIC machen willst, brauchst Du mindestens zwei physikalische NICs, egal wie Du's drehst oder wendest.
 
Ich glaube, ich habe eine Info vergessen: an die physikalische Konsole komme ich via KVM noch dran. CLI Konfigurationen kann ich also noch machen.

Edit: ich hatte vorhin mal an einem Server mit mehreren NICs getestet. Entweder habe ich einen Fehler gemacht, oder ich kann einen vSwitch aus Maintenance vmk und VMNetwork aber ohne Physikalische NIC nicht mehr an eine VM hängen.
 
Zuletzt bearbeitet:
Direktes Passthrough sollte nicht nötig sein. Wenn an dem vSwitch, in dem die NIC ist, kein vKernel-Interface mehr hängt, dann ist der ESXi auch nicht mehr per IP erreichbar. Der Vorteil wäre, dass du das mit richtiger Vorbereitung mit einem Klick umschalten kannst bzw. sogar parallel direkten Zugriff und Zugriff durch die Router-VM ermöglichen kannst. Soweit ich weiß, leitet ein vSwitch nur noch Ethernet-Frames weiter und stellt keine Dienste mehr bloß, wodurch es sicherheitstechnisch schon gut dasteht.
 
Ich verstehe das anliegen von martingo schon - die Management-Oberfläche des Hosts soll durch die VM geschützt sein, aber das ist im Zweifel ein Henne-Ei-Problem, wenn mal was hackt.
Ich vermute, das ganze ist für einen Host im Rechenzentrum?

Man müsste quasi ein 2 vSwitch anlegen, auf beiden die Management-Funktionen und alles legen, das eine ist mit NIC-A angebunden, das andere ohne NIC, dafür aber quasi mit der Router-VM
nun nimmt man NIC-B und macht per Passthrough die Einstellungen - wenn man dann über die Router-VM auf die Management-Oberfläche am 2ten vSwitch ohne NIC kommt (das natürlich ein anderes Subnet sein muss), kann man probieren, die NIC-A zu entfernen.

Ein anderes vorgehen sehe ich leider nicht.

-> Mehrere Management-IPs sind kein Problem, habe ich hier auch schon gehabt, für Hosts, die immer mal in unterschiedlichen Umgebungen eingesetzt werden, aber @LAB auch ohne groß nachkonfigurieren funktionieren.
 
Richtig, geht um einen Server bei Hetzner.
Ein Passthrough hätte einige Vorteile:
- ich kann die Haupt IP produktiv nutzen (nicht nur als Wartungs IP für den ESXi)
- ich spare mir virtuelle Interfaces mit virtuellen MACs auf der Router VM (jede zusätzliche Einzel-IP wird für Virtualisierung bei Hetzner auf jeweils eine eigene virtuelle MAC geroutet, die vorgegeben wird)
- ich kann ESXi deutlich besser schützen. Gestern konnte ich mich beispielsweise nicht mehr am Webinterface einloggen, weil über SSH Bruteforce Logins reinkamen und ESXi dann komplett zugemacht hat
- die vorgeschaltete (webkonfigurierbare) Firewall bei Hetzner ist mega umständlich und nicht sehr umfangreich

Die reguläre ESXi Wartung würde ich dann über VPN zur RouterVM machen wollen.
Dass es problematisch ist, den Ast abzusägen, auf dem ich sitze, ist klar. Nachdem aber bei Bedarf jederzeit ein KVM Interface angeschlossen wird, könnte ich ESXi zur Einrichtung und im Problemfall über die Kommandozeile administrieren.
Das setzt aber voraus, dass jegliche Konfiguration auch über CLI machbar ist und dass mein Vorhaben grundsätzlich überhaupt funktioniert.

Edit: Diese Beispielkonfiguration würde ich quasi so umbiegen wollen, dass vswitch0 entfällt, phys0 direkt in die routervm geht und config interface/VMkernel an vswitch1 hängt:
Zusaetzliche IP-Adressen – Hetzner DokuWiki
 
Zuletzt bearbeitet:
Nein? Kannst Du das etwas weiter ausführen?
Mein gedanklicher Horizont ist beim ersten Punkt schon erreicht. Die Haupt-IP wird fix auf die MAC-Adresse der physikalischen NIC geroutet. Wie kommen die Pakete dann in die Router VM? Physikalische MAC ändern ist wahrscheinlich nicht besonders elegant :)
 
Nagel mich jetzt nicht fest, man müsste das ausprobieren, aber: Zwei identische MAC-Adressen in einem Ethernet-Segment sind kein Problem, wenn eine davon nicht kommuniziert. Ob der vSwitch das mitmacht, wäre zu testen. Ansonsten die physikalische MAC-Adresse ändern und der VM die ursprüngliche MAC-Adresse geben.
 
Ja, die MAC-Adressen Änderung war das einzige, was ich mir noch vorstellen konnte. Es wird also in jedem Fall die physikalische MAC auch in der Router VM gebraucht?
Wenn wir mal bei diesem Bild bleiben:
https://wiki.hetzner.de/images/1/1f/X-bridge.png
Du würdest quasi fast alles so lassen, nur "config interface/VMkernel" von vswitch0 auf vswitch1 umhängen?

Ich frage mich halt: hat das irgendeinen Vorteil? Man könnte etwas mehr vorbereiten und müsste Passthrough nicht per CLI aktivieren, aber "sauberer" wäre doch die Passthru Lösung, oder nicht?
 
die Lösung mit Passthrough hat halt ihre tücken.

die vSwitch-Variante ist halt die einfachste Lösung - einzige Frage - wie willst Du das eben jetzt lösen, Du brauchst temporär 2 Adressen, da Du weder dem ESX Mgmt noch der Router-VM outside die gleiche zur selben Zeit geben kannst...? - außer Du machst auf der Mgmt-Oberfläche nur IPv6, das geht natürlich auch, wäre ggf. sogar eine relativ elegante Lösung, ohne den ganzen Rest anpacken zu müssen.
 
Kurze Frage: Kann man eine VM auf den selben USB-Speicher ablegen, auf dem ESXi installiert ist?

Bereite gerade mein erstes System mit ESXi vor, wollte ESXi und FreeNAS auf ein externes USB3-RAID1-SSD-Gehäuse mit zwei Samsung SM863a 240 GB (wegen Powerloss Protection) installieren und das laufende FreeNAS stellt dann den Speicher vom PCH-SATA-Controller via VT-d (über NFS?) für weitere VMs bereit.

Mag vielleicht etwas Overkill sein, mir ist es aber sehr wichtig, dass das System nicht abkackt, wenn eine einzelne SSD ausfallen sollte.
 
Beides in einem Datastore ist kein Problem.
Frage mich nur, ob der hohe Preis für diese SSDs gerechtfertigt ist. Was bieten die denn noch außer Powerloss Protection (und vermutlich etwas mehr TBW)? Für dieses Geld könnte man ja auch zwei "normale" SSDs kaufen und dazu noch eine schöne APC-USV, um den ganzen Server abzusichern und hätte noch ordentlich Was übrig..
 
Danke für die Hilfe!
Die SSDs sind bereits von einem anderen Projekt vorhanden, daher wollen sie genutzt werden :)
Eine USV kommt noch separat, wenn die Hardware-Konfiguration abgeschlossen ist und die Bastelei ein Ende hat.

Das Tower-System kommt in eine kleine (belüftete) Abstellkammer, wo jedes bisschen Raum knapp ist, daher möchte ich die USV erst am Ende dazustellen, wenn genau klar ist, wie viel Platz um das PC-Gehäuse und das separate 3,5"-Gehäusekonstruktion übrig bleibt, nicht dass es dann um zwei Zentimeter nicht passt.
 
Ist es richtig, dass man bei VMware als ESXi Free-Nutzer nur die ziemlich veraltete 6.50a-Setup-ISO herunterladen kann und nichts aktuelles, so dass man manuell patchen muss, auch bei einer vollständigen Neuinstallation?

Fimde das ziemlich beknackt, nachdem ich im VMware-Konto-Downloadbereich nur die 6.50a finden konnte, habe ich etwas gegooglet und das kam dabei raus.

Kann das jemand hier bestätigen?
 
Die aktuelle zum Download ist 6.5U1. Die läuft recht gut (man muss allenfalls bei Editieren einer VM und einem Memory Error ab und an F5/reload drücken)

Die Vmware Seite ist aber bescheuert da die neueren Downloads schwer zu finden sind und man die dann erst zu seinem Account hinzufügen muss. Meistens führt Googeln nach "vsphere 6.5 u1 iso" zum Erfolg

z.B.
Download VMware vSphere
 
Zuletzt bearbeitet:
Anmelden, um zu antworten.
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