Mit Hyper-V sind die Anforderungen entspannter. Windows 11 in einer virtuellen Maschine installieren 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.
ESX / ESXi - Hilfethread
- Ersteller XTaZY
- Erstellt am
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.
Jupp. Ob das bei Hyper-V auch nicht vorher so war keine Ahnung. Ich habe mit Hyper-V sehr wenig Erfahrung, daher kein Plan.
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
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.
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.
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.
besterino
Legende
Neeee. Da am besten Bifurcation Auto oder off.
Wo sind denn die 4 NVMEs drin?
Wo sind denn die 4 NVMEs drin?
Auto hatte nicht funktioniert. Dann versuche ich es einmal mit "off".
besterino
Legende
Ansonsten vielleicht mal einen anderen Slot versuchen.
Off gibt es nicht, deshalb bin ich nochmal auf "Auto". Hat aber auch nicht geholfen.
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.
besterino
Legende
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.
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.
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.
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:
ESX + vCenter sind die jeweils aktuellsten Versionen. Falls jemand eine Idee hat, immer her damit
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:
ESX + vCenter sind die jeweils aktuellsten Versionen. Falls jemand eine Idee hat, immer her damit
Luckysh0t
Enthusiast
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
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 ^^
Das könnte/wird dein Problem sein.
Zuletzt bearbeitet:
Happy Hepo
Experte
- Mitglied seit
- 16.01.2017
- Beiträge
- 225
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...
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:
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?
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
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.
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:
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 ist Sinn und Zweck der Sache: alles (was man will) verschlüsselt, ohne MasterKey Instanz (vCenter / KMS / NKP) kein Zugriff.
Nur wenn Du kein Backup hast. Aber das würde einem fachkundigen IT Profi niemals passieren
Beitrag automatisch zusammengeführt:
Genau so isses.
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.
Luckysh0t
Enthusiast
Für den ein oder anderen privat bzw. beruflich von Interesse.
Removal of SD card/USB as a standalone boot device option
Luckysh0t
Enthusiast
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 ^^
In der Firma laufen die auf ssd mirrors - für irgendwas muss man ja den lokalen Storage nutzen ^^
Trambahner
Urgestein
Wofür wäre das interessant?