ESX / ESXi - Hilfethread

Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich weiß ist kein ESXI, aber da frage ich mich doch warum es VMware nicht dem Anwender überlässt, wie er das TPM implementieren will.
Einfach gesagt: TPM & Key Management war bisher nur dazu gedacht, bei Bedarf (große) Strukturen abzusichern / abzudichten. Den Fall, das ein simples Desktop OS zwingend SecureBoot+TPM erfordert, gabs bisher noch nicht, da war das immer optional.

Alles Dinge, die den Charme Faktor von Win11 nicht wirklich steigern.
 
Einfach gesagt: TPM & Key Management war bisher nur dazu gedacht, bei Bedarf (große) Strukturen abzusichern / abzudichten.
Jupp. Ob das bei Hyper-V auch nicht vorher so war keine Ahnung. Ich habe mit Hyper-V sehr wenig Erfahrung, daher kein Plan.
Alles Dinge, die den Charme Faktor von Win11 nicht wirklich steigern.
Ich finde es nicht schlecht das Sicherheitsfeatures notfalls auch mit etwas "Zwang" durchgesetzt werden. Solange es Alternativen gibt ist ja keiner gezwungen W11 oder alle mit auf den Zug springenden Software zu benutzen.
 
Ich finde es nicht schlecht das Sicherheitsfeatures notfalls auch mit etwas "Zwang" durchgesetzt werden. Solange es Alternativen gibt ist ja keiner gezwungen W11 oder alle mit auf den Zug springenden Software zu benutzen.
Das hat mit Sicherheit nur dahin gehend was zu tun, das der Benutzer mit Sicherheit nichts mehr am OS verändert.

Und dann werden als nächstes OS basierende Inhaltsfilterungen, HDD Scans und ePerso Zwangsauthentifizierungen nachgeschoben.
 
Das ist die Kehrseite der Medaille.

Lass uns aber mal wieder BTT gehen :-)
 
Hallo,

nachdem ich jetzt mein Mainboard + zugehörigen Prozessor getauscht habe, kann ich kein "Passthrough" mehr für meine 4 NVMe SSDs in einer QNAP Multi SSD-Karte aktivieren. Es steht dort "Neustart erforderlich". Starte ich den Server neu, so steht immer noch "Neustart erforderlich" dort und ich kann die SSDs nicht an eine VM durchreichen, da Passthrough nicht für die SSDs aktiviert ist. Für z.B. zwei Quadro P600 oder die 2 HBAs ist Passthrough aktiviert und diese lassen sich auch problemlos an VMs durchreichen.

Mainboard: H11SSL-I
Prozessor: Epyc 7551P
ESXi: 7.02
SSDs: 4x Sandisk Extreme Pro in QNAP QM2-4P-384

Mit dem alten Board (X11SCH-F mit Xeon 2146G) hat dies funktioniert.

Im Bios ist SVM enabled, IOMMU ist enabled und ACS ist auf AUTO gestellt,

Hat vielleicht jemand eine Idee, was ich noch machen muss, damit ich den Passthrough für die SSDs aktivieren kann.
 
CPU2 SLOT1 PCI-E 3.0 X8 Bifurcation
This setting selects the bifurcation configuration for this particular PCI-E slot. Options include
Auto, and x4x4.
CPU1 SLOT2 PCI-E 3.0 X16 Bifurcation
This setting selects the bifurcation configuration for this particular PCI-E slot. Options include
Auto, x8x8 and x4x4x4x4.
CPU1 SLOT3 PCI-E 3.0 X8 Bifurcation
This setting selects the bifurcation configuration for this particular PCI-E slot. Options include
Auto, and x4x4.
CPU1 SLOT4 PCI-E 3.0 X16 Bifurcation
This setting selects the bifurcation configuration for this particular PCI-E slot. Options include
Auto, x8x8 and x4x4x4x4.
CPU1 SLOT5 PCI-E 3.0 X8 Bifurcation
This setting selects the bifurcation configuration for this particular PCI-E slot. Options include
Auto, and x4x4.
CPU1 SLOT6 PCI-E 3.0 X16 Bifurcation
This setting selects the bifurcation configuration for this particular PCI-E slot. Options include
Auto, x8x8 and x4x4x4x4.

Da sind die richtigen Einstellungen gesetzt ? 4x4x4x4 würde ich vermuten wenn du die SSD einzeln durchreichen willst.
 
Da sind die richtigen Einstellungen gesetzt ? 4x4x4x4 würde ich vermuten wenn du die SSD einzeln durchreichen willst.
Sorry, hatte ich vergessen zu schreiben, für den Slot, in welchem die QNAP-Karte steckt (Slot 5), habe ich x4x4 für Bifurcation eingestellt. Für die anderen Slots habe ich alles auf "Auto" stehen.
 
Neeee. Da am besten Bifurcation Auto oder off.

Wo sind denn die 4 NVMEs drin?
 
Ansonsten vielleicht mal einen anderen Slot versuchen.
 
Neeee. Da am besten Bifurcation Auto oder off.
Off gibt es nicht, deshalb bin ich nochmal auf "Auto". Hat aber auch nicht geholfen.
Ansonsten vielleicht mal einen anderen Slot versuchen.
Nachdem ich die Karte in einen anderen Slot gesteckt habe, geht der komplette Rechner nicht mehr bzw. die LAN-Ports "connecten" nicht mehr. Aber da dies nichts mit ESXi zu tun hat (IPMI ist auch nicht mehr erreichbar), mache ich einen separaten Thread auf.
 
Oha. Das ist in der Tat etwas seltsam.
 
2-4-6 wären die richtigen Slots bei 4 NVME Karten. 2x4 Slot kann nicht funktionieren.

Falls ich da ein Denkfehler habe, gerne berichtigen.

@besterino Das kenne ich von meinem Supermicro auch. Das war aber eine Raidkarte die in gewissen Slots einfach nicht ging, bzw. nicht erkannt wurde oder halt auch kein Boot möglich war.
 
Status vTPM@ESX

1) man benötigt zwingend ein vCenter
2) man benötigt zwingend einen externen KMS

oder

3) ab Version 7.02 für vCenter und ESX gibt es ein neue Feature: im vCenter gibt es jetzt eine neue Funktion "Native Key Provider", die für TPM ausreichend ist.


NKP + vCenter laufen schon, aber irgendwas hakt da noch wenn man für eine VM die Storage Policy auf "encrypted" setzen möchte:
A general runtime error occurred. Key Provider <NKP des Hosts> is not compatible with the host <meinESX>. Reason: "The host does not support Native Key Provider."

ESX + vCenter sind die jeweils aktuellsten Versionen. Falls jemand eine Idee hat, immer her damit ;)
 
NKP + vCenter laufen schon, aber irgendwas hakt da noch wenn man für eine VM die Storage Policy auf "encrypted" setzen möchte:

ESX + vCenter sind die jeweils aktuellsten Versionen. Falls jemand eine Idee hat, immer her damit ;)

vSphere Native Key Provider Requirements​


To use vSphere Native Key Provider, you must:


  • Ensure that both the vCenter Server system and ESXi hosts are running vSphere 7.0 Update 2 or later.
  • Configure the ESXi hosts in a cluster.
  • Use the fully-qualified domain name (FQDN) of the vCenter Server system when accessing it with the vSphere Client.
  • Configure the vCenter Server file-based backup and restore and store the backups securely as they contain the Key Derivation Key. See the topic on vCenter Server backup and restore in vCenter Server Installation and Setup.

To perform vSphere Virtual Machine Encryption or vSAN encryption using vSphere Native Key Provider, you must purchase the edition of those products containing the appropriate license.
 
Die QNAP QM2-4P-384 ist eine PCIe x8 Karte. Also müssten die Slots 1,3 und 5 funktionieren. Laut Nummerierung im Mainboard Handbuch sind 2,4 und 6 die PCIe x16 Slots.
Mit den genannten Ports kannst du aber nur 2 Fach Aufteilen. Oder ist das egal? Ich hab da kein Plan von daher halte ich jetzt die Schnute ^^
  • Configure the ESXi hosts in a cluster.
Das könnte/wird dein Problem sein.
 
Zuletzt bearbeitet:
Da ein PCIe Switch auf der QNAP-Karte sitzt, würde ich vermuten dass die generell kein bifurcation benötigt. Wenn es mit Bifurcation Auto nicht klappt, ist die Karte eventuell generell nicht mit dem Board kompatibel (wie in den anderen Slots)
 
Da ein PCIe Switch auf der QNAP-Karte sitzt, würde ich vermuten dass die generell kein bifurcation benötigt. Wenn es mit Bifurcation Auto nicht klappt, ist die Karte eventuell generell nicht mit dem Board kompatibel (wie in den anderen Slots)
Ja, das könnte natürlich sein. Da aber der BMC jetzt nicht mehr reagiert, muss ich jetzt erstmal schauen, was da los ist...
 
w11_esx_mit_tpm_blur.jpg


So ich habs jetzt!

Im Prinzip überschaubar, aber mit ein paar Fußangeln weil die VMware Anleitungen teilweise verschachtelt und nicht wirklich Step-by-Step sind.


Hier mal die Kurzform:

ESX - muss Version 7.0u2 (Enterprise Plus) oder höher sein, aktuell ist 7.0u2d
vCenter - muss Version 7.0u2 oder höher sein, aktuell ist 7.0u2c

Hardware TPM am ESX Host ist optional, kann man benutzen, muss man aber nicht!

Für das vCenter muss es einen funktionierenden DNS - FQDN geben, d.h. die Verwendung von z.B. "vcenter.local" muss die korrekte IP Adresse zurückgeben.
Weil: der erzeugte Key aus dem NKP <muss> zwingend vorher abgespeichert werden, vorher kann man den Key nicht verwenden.
Aus irgendeinem unerfindlichen Grund kann man zwar das gesamte vCenter per Browser mit https://<meine_vcenter_ip> benutzen,
aber das Backup des Keys klappt nicht. Steht auch so im Handbuch... schön tief vergraben.
Heisst konkret: das vCenter muss an dieser Stelle mit "https://vcenter.local" gestartet werden, sonst kein Backup.

Ich habe das bei mir mit dem FQDN gelöst, in dem im Router einen manuellen Eintrag gesetzt habe, weil kein DC mit DNS vorhanden im HomeLab.

Der bei der Installation des vCenter "optionale" FQDN (vcenter.local) muss bei der Installation richtig gesetzt sein.
Kann man später theoretisch ändern, ist aber sehr aufwändig und eben auch wieder eine Fehlerquelle.
Der FQDN muss sich logischerweise mit dem decken, was der DNS zurück gibt.


Wenn das soweit steht, im vCenter folgendes machen:
1) configure - security - key providers - ADD: native key provider (NPK) - Name vergeben
2) NPK Key sichern - geht nur wenn das vCenter per FQDN gestartet wurde
3) Datacenter anlegen
4) im Datacenter einen Cluster anlegen und mindestens den 1 Host zufügen, wo die VM mit TPM laufen soll

Die fertige Struktur ist also wie folgt:
--[vcenter.local]
-----[my_datacenter]
----------[my_cluster]
---------------[my_esx_host]
-------------------- VM_1
---------------------VM_2

Der Cluster Layer ist zwar für einen Stand-Alone Host komplett sinnfrei (wie ein Raid-0 mit nur 1 Member),
aber VMware will das halt so, sonst gehts nicht.


Konfiguration der VM:
1) Hardware Version muss 14 oder höher sein
2) Boot Mode EFI
3) SecureBoot einschalten

vCenter: VM -> rechtsklick - VM policies -> Edit Storage Policies -> Umstellen auf "VM Encryption policy" + ok
Datenträger wird verschlüsselt, wenn fertig:

4) VM Edit Config: Add other Device - TPM

Fertig.


Und logischerweise: (Auto) Backups des NPK Keys und der vCenter Instanz. Sonst sind die VMs etc nicht mehr verwendungsfähig, wenn das vCenter sich mal zerlegen sollte.
 
Zuletzt bearbeitet:
So ich habs jetzt!

Im Prinzip überschaubar, aber mit ein paar Fußangeln weil die VMware Anleitungen teilweise verschachtelt und nicht wirklich Step-by-Step sind.
Ne aktuelle Dev Build hast du nicht zufällig am laufen?
Der Test ist wahrscheinlich sooooo viel nicht wert, den die 194er PreRelease Insider Build läuft auch ohne TPM und mit nicht supportetem Prozessor auf nem (in meinem Fall) 6.7U3 Free Host ohne vCenter und ohne das KMS Geraffel. Patches via WSUS bereit gestellt.
Hatte vorhin nur das Problem, dass das WSL Update für Graphics Driver Support oder wie sich das schimpfte, nicht installierbar war, das lag aber an irgend so einem Preview WSL Paket, was die ersten offiziellen Insider Builds mitbrachten bzw. anforderten vom Update Dienst.

Soweit ich das aber bis dato gelesen habe, hat MS in den Dev Builds jetzt die Anforderungen erst aktiv geschalten. Ob das Zeugs also auch tut, sieht man zumindest nicht mit der 194er Build, denn die geht auch ohne.
Achso, OnPrem AD gejoint ist die Kiste bei mir noch - kann mir aber nur schwer vorstellen, dass das einen Unterschied macht.

Ansich ist das, was VMware da aber mit vTPM macht, schon bissi eigen. Auf der Workstation geht das auch Single und ohne Umwege. Der Single ESXi Host muss wohl (hab ich noch nicht getestet) auch ohne vCenter in der Lage sein, mindestens mal die VCSA Appliance zu starten - sprich da is ja noch gar kein vCenter online. Da muss es denke ich noch nen Trick geben, wie man dem Zeug das reingeimpft bekommt... Oder es werden sich alle wundern, die VCSA Appliance mit dem ganzen Verschlüsslungsstuff im gleichen Verbund betreiben wie ihre KMS Appliances und andere VMs. Das ließt sich nämlich wie, ohne VCSA und KMS nix entschlüsseln. Und nach ner Power Outage is dann Ruhe? Oder hab ich irgendwo nen Denkfehler?
 
Ne aktuelle Dev Build hast du nicht zufällig am laufen?
Nein, ich habe das W11 vor ~2 Monaten zum reinschauen per uudump.net generierten ISO in einer VM installiert und seitdem nur die Updates laufen lassen. Aufgrund der News Meldung vor ein paar Tagen, die besagte das die Voraussetzungen für VMs angezogen bzw mit nativer Installation gleich gesetzt werden, habe ich mich mal intensiver mit vTPM beschäftigt, um zu schauen ob das auf einem ESX praktikabel ist und welcher Aufwand dahinter steht.

In 15 Tagen ist Final Release von Win11, ev. gibts vorher noch Updates oder halt spätestens dann kann ich dazu mehr sagen.
 
@fdsonne
Einfach gesagt: TPM & Key Management war bisher nur dazu gedacht, bei Bedarf (große) Strukturen abzusichern / abzudichten.
Wie Supaman schon treffend schrieb. Daher auch die Cluster Vorgabe etc. Für ein Single Host natürlich sehr umständlich und aufwendig.

Bei meinem Versuch ohne vCenter mit einer reinkopierten VM ging es nicht. Da wurde die VM zwar eingebunden aber dann als ungültig deklariert. Du denkst da schon in den richtigen Bahnen.

Uns ging es in erster Linie darum, das wir das TPM in der VM für die Installation aktiv geschaltet bekommen. Und das geht bisher nur über den Weg wie von Supaman beschrieben.

Vermutlich wird aber einfach zuerst die VCSA Appliance gestartet werden müssen und dann die verschlüsselten VM. Sonst ist es Banane mit der Erkennung und Entschlüsselung.
Dabei ist natürlich die super "Sinnvolle" Sache von VmWare, das eine externe nicht auf einem ESXI gehostete VCSA Appliance gewünscht/zugelassen/verfügbar ist/wird.
 
Zuletzt bearbeitet:
Der Single ESXi Host muss wohl (hab ich noch nicht getestet) auch ohne vCenter in der Lage sein, mindestens mal die VCSA Appliance zu starten - sprich da is ja noch gar kein vCenter online.
Man hat 2 Möglichkeiten:
1) auf der vCenter ISO ist ein OVA Template, das man im ESX importieren kann
2) auf der vCenter ISO ist ein Installer, der auf dem ESX eine vCenter inkl. der Custom Parameter erzeugt

Das ließt sich nämlich wie, ohne VCSA und KMS nix entschlüsseln.
Das ist Sinn und Zweck der Sache: alles (was man will) verschlüsselt, ohne MasterKey Instanz (vCenter / KMS / NKP) kein Zugriff.

Und nach ner Power Outage is dann Ruhe? Oder hab ich irgendwo nen Denkfehler?
Nur wenn Du kein Backup hast. Aber das würde einem fachkundigen IT Profi niemals passieren ;)
Beitrag automatisch zusammengeführt:

Uns ging es in erster Linie darum, das wir das TPM in der VM für die Installation aktiv geschaltet bekommen. Und das geht bisher nur über den Weg wie von Supaman beschrieben.
Genau so isses.
Vermutlich wird aber einfach zuerst die VCSA Appliance gestartet werden müssen und dann die verschlüsselten VM. Sonst ist es Banane mit der Erkennung und Entschlüsselung.
Korrekt. Beim Start fordert die VM über den ESX Host und dann über das vCenter die Keys an, die dann im Arbeitsspeicher des ESX verbleiben. Wenn ich das ricthtig in Erinnerung habe, könnte man nach Start der VM das vCenter bzw den KMS runterfahren, sofern nicht anderweitig benötigt.
 
<Eigentlich> hinfällig, weil die Installation auf USB Stick überflüssig geworden ist. Alleine aus Gründen der Ausfallsicherheit würde ich immer eine kleine SSD nehmen, die Dinger kosten heutzutage ja fast nichts mehr.
 
Stimmt schon. Wobei ich bei meinem Mini esxi Server auch noch auf USB Stick setze.

In der Firma laufen die auf ssd mirrors - für irgendwas muss man ja den lokalen Storage nutzen ^^
 
Ich finde es wesentlich nerviger, das man seit ESX 7 einen Datastore, den man auf dem Rest vom Installationslaufwerk angelegt hat, die Größe nicht verändern kann ohne den DS komplett zu löschen.
 
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