Microsoft System Center Virtual Machine Manager-Virtualisierungsumgebungen
Befolgen Sie die nachfolgenden Anweisungen, wenn Sie Hyper-V mit Microsoft System Center Virtual Machine Manager (VMM) zur Bereitstellung von virtuellen Maschinen verwenden.
Dieses Release unterstützt die im Artikel Systemanforderungen aufgeführten VMM-Versionen.
Verwenden Sie Provisioning Services und Maschinenerstellungsdienste zum Bereitstellen folgender Elemente:
- Desktop- oder Serverbetriebssystem-VM der ersten Generation
- Windows Server 2012 R2-, Windows Server 2016- und Windows 10-VM (mit oder ohne sicheren Start) der zweiten Generation
Aktualisieren von VMM
-
Upgrade von VMM 2012 auf VMM 2012 SP1 oder VMM 2012 R2
Informationen zu VMM- und Hyper-V-Hosts finden Sie unter https://docs.microsoft.com/en-us/previous-versions/system-center/system-center-2012-R2/gg610649(v=sc.12)?redirectedfrom=MSDN. Informationen zu VMM-Konsolenanforderungen finden Sie unter https://docs.microsoft.com/en-us/previous-versions/system-center/system-center-2012-R2/gg610640(v=sc.12)?redirectedfrom=MSDN.
Ein gemischter Hyper-V-Cluster wird nicht unterstützt. Ein gemischter Cluster ist beispielsweise einer, bei dem eine Hälfte des Clusters Hyper-V 2008 und die andere Hälfte Hyper-V 2012 ausführen.
-
Upgrade von VMM 2008 R2 auf VMM 2012 SP1
Wenn Sie ein Upgrade von XenDesktop 5.6 unter VMM 2008 R2 ausführen, halten Sie folgende Reihenfolge ein, um die Ausfallzeit von XenDesktop möglichst kurz zu halten:
- Upgrade von VMM auf 2012 (jetzt XenDesktop 5.6 und VMM 2012)
- Upgrade von XenDesktop auf die aktuelle Version (jetzt aktuelle XenDesktop-Version und VMM 2012)
- Upgrade von VMM von 2012 auf 2012 SP1 (jetzt aktuelle XenDesktop-Version und VMM 2012 SP1)
-
Upgrade von VMM 2012 SP1 auf VMM 2012 R2
Wenn Sie ein Upgrade von XenDesktop oder XenApp 7 unter VMM 2012 SP1 ausführen, halten Sie folgende Reihenfolge ein, um die Ausfallzeit von XenDesktop möglichst kurz zu halten:
- Upgrade von XenDesktop oder XenApp auf die aktuelle Version (jetzt aktuelle XenDesktop-/XenApp-Version und VMM 2012 SP1)
- Upgrade von VMM 2012 SP1 auf 2012 R2 (jetzt aktuelle XenDesktop- oder XenApp-Version und VMM 2012 R2)
Zusammenfassung von Installation und Konfiguration
Wichtig:
Alle Delivery Controller müssen in derselben Gesamtstruktur sein wie die VMM-Server.
- Installieren und konfigurieren Sie einen Hypervisor.
- Installieren Sie Microsoft Hyper-V Server und VMM auf Ihren Servern.
- Installieren Sie die System Center VMM-Konsole auf allen Controllern. Die Konsolenversion muss mit der Version des Verwaltungsservers übereinstimmen. Obwohl eine frühere Konsole eine Verbindung zum Verwaltungsserver herstellen kann, schlägt die Bereitstellung von VDAs fehl, wenn die Versionen sich unterscheiden.
- Überprüfen Sie die folgenden Kontoinformationen:
-
Das Konto, das Sie zum Festlegen von Hosts in Studio verwenden, ist ein VMM-Administrator oder delegierter VMM-Administrator für die relevanten Hyper-V-Maschinen. Wenn dieses Konto nur über die delegierte Administratorrolle in VMM verfügt, werden die Speicherdaten in Studio beim Erstellen des Hosts nicht aufgeführt.
-
Das Benutzerkonto, das für die Studio-Integration verwendet wird, muss auch Mitglied der lokalen Administratorsicherheitsgruppe auf jedem Hyper-V-Server sein, um zur Lebenszyklusverwaltung von VM (z. B. VM erstellen, aktualisieren und löschen) berechtigt zu sein. Hinweis: Die direkte Installation eines Controllers auf einem Server, auf dem Hyper-V ausgeführt wird, wird nicht unterstützt.
-
- Erstellen Sie eine Master-VM.
- Installieren Sie einen Virtual Delivery Agent auf der Master-VM und wählen Sie die Option zur Desktopoptimierung aus. Dies verbessert die Leistung.
- Erstellen Sie einen Snapshot der Master-VM, um diesen als Sicherungskopie zu verwenden.
- Erstellen Sie virtuelle Desktops. Bei Verwendung von MCS zum Erstellen von VM beim Erstellen einer Site oder einer Verbindung:
- Wählen Sie den Typ des Microsoft-Virtualisierungshosts aus.
- Geben Sie die Adresse als vollqualifizierten Domänennamen des Hostservers ein.
- Geben Sie die Anmeldeinformationen für das zuvor erstellte Administratorkonto ein, das Berechtigungen zum Erstellen von VM enthält.
- Wählen Sie im Dialogfeld Hostdetails den Cluster oder eigenständigen Host aus, der beim Erstellen der neuen VMs verwendet werden soll. Wichtig: Sie müssen auch dann zu einem Cluster oder eigenständigen Host navigieren und diesen auswählen, wenn Sie eine Bereitstellung mit einem einzelnen Hyper-V-Host verwenden.
MCS auf SMB 3-Dateifreigaben
Bei Maschinenkatalogen, die mit MSC auf SMB 3-Dateifreigaben für VM-Speicher erstellt wurden, müssen Sie darauf achten, dass die Anmeldeinformationen die nachfolgenden Anforderungen erfüllen, damit Aufrufe von der Hypervisor Communications Library (HCL) des Controllers die Verbindung mit dem SMB-Speicher herstellen:
- Die VMM-Benutzeranmeldeinformationen müssen vollständigen Lese-/Schreibzugriff auf den SMB-Speicher umfassen.
- Speichervorgänge auf dem virtuellen Datenträger werden bei Vorgängen im Lebenszyklus der VM über den Hyper-V-Server mit den VMM-Anmeldeinformationen durchgeführt.
Wenn Sie SMB als Speicher verwenden, aktivieren Sie das Feature “CredSSP” (Credential Security Support Provider) vom Controller auf den einzelnen Hyper-V-Maschinen, wenn Sie VMM 2012 SP1 mit Hyper-V unter Windows Server 2012 verwenden. Weitere Informationen finden Sie unter CTX137465.
Über eine standardmäßige Remote-PowerShell V3-Sitzung verwendet die HCL CredSSP zum Öffnen einer Verbindung mit der Hyper-V-Maschine. Dieses Feature übergibt mit Kerberos verschlüsselte Benutzeranmeldeinformationen an die Hyper-V-Maschine. Die PowerShell-Befehle in dieser Sitzung auf der Remotemaschine mit Hyper-V werden dann unter Verwendung der angegebenen Anmeldeinformationen (in diesem Fall, derer des VMM-Benutzers) ausgeführt, sodass eine ordnungsgemäße Kommunikation mit dem Speicher gewährleistet wird.
Die folgenden Tasks verwenden PowerShell-Skripts der HCL, die an die Hyper-V-Maschine zur Verwendung mit SMB 3.0-Speicher gesendet werden.
-
Konsolidieren des Masterimages: Ein Masterimage erstellt ein neues MCS-Provisioningschema (Maschinenkatalog). Die Master-VM wird durch dieses Schema geklont und vereinfacht, damit sie zum Erstellen neuer VM aus dem neu erstellten Datenträger bereit ist (die Abhängigkeit zur ursprünglichen Master-VM wird entfernt).
ConvertVirtualHardDisk im Namespace root\virtualization\v2
Beispiel:
$ims = Get-WmiObject -class $class -namespace "root\virtualization\v2"; $result = $ims.ConvertVirtualHardDisk($diskName, $vhdastext) $result -
Erstellen eines differenzierenden Datenträgers: erstellt einen differenzierenden Datenträger aus dem Masterimage, das durch Konsolidierung des Masterimages generiert wurde. Der differenzierende Datenträger wird dann an eine neue VM angeschlossen.
CreateVirtualHardDisk im Namespace root\virtualization\v2
Beispiel:
$ims = Get-WmiObject -class $class -namespace "root\virtualization\v2"; $result = $ims.CreateVirtualHardDisk($vhdastext); $result -
Upload von Identitätsdisks: Von der HCL kann die Identitätsdisk nicht direkt in den SMB-Speicher hochgeladen werden. Daher muss der Identitätsdatenträger von der Hyper-V-Maschine hochgeladen und in den Speicher kopiert werden. Da die Hyper-V-Maschine die Disk nicht auf dem Controller lesen kann, muss sie von der HCL zuerst wie folgt über die Hyper-V-Maschine kopiert werden:
-
Upload der Identitätsdisk durch die HCL auf die Hyper-V-Maschine über die Administratorfreigabe.
-
Der Datenträger wird von der Hyper-V-Maschine über ein PowerShell-Skript, das in der Remote-PowerShell-Sitzung ausgeführt wird, in den SMB-Speicher kopiert. Auf der Hyper-V-Maschine wird ein Ordner erstellt, dessen Berechtigungen nur für den VMM-Benutzer gesperrt sind (über die remote PowerShell-Verbindung).
-
Die HCL löscht die Datei aus der Administratorfreigabe.
-
Wenn der Upload des Identitätsdatenträgers durch die HCL auf die Hyper-V-Maschine abgeschlossen ist, werden die Identitätsdatenträger von der Remote-PowerShell-Sitzung in den SMB-Speicher kopiert und dann aus der Hyper-V-Maschine gelöscht.
Falls der Ordner des Identitätsdatenträgers gelöscht wird, wird er neu erstellt, damit er zur Wiederverwendung verfügbar ist.
-
-
Download von Identitätsdisks: Wie beim Upload wird die Identitätsdisk über die Hyper-V-Maschine an die HCL übergeben. Beim folgenden Prozess wird, falls noch nicht vorhanden, ein Ordner erstellt, der nur VMM-Benutzerbenutzerberechtigungen auf dem Hyper-V-Server hat.
- Die Disk wird von der Hyper-V-Maschine aus dem SMB-Speicher in den lokalen Hyper-V-Speicher kopiert, und zwar über ein PowerShell-Skript, das in der Remote-PowerShell V3-Sitzung ausgeführt wird.
- Die HCL liest den Datenträger aus der Administratorfreigabe der Hyper-V-Maschine in den Speicher.
- Die HCL löscht die Datei aus der Administratorfreigabe.
-
Erstellen einer persönlichen vDisk: Wenn der Administrator die VM in einem Personal vDisk-Maschinenkatalog erstellt, muss eine leere Disk (PvD) erstellt werden.
Der Aufruf zum Erstellen einer leeren Disk erfordert keinen direkten Zugriff auf den Speicher. Wenn Sie PvDs auf anderen Speichern als dem Haupt- oder dem Betriebssystemdatenträger haben, verwenden Sie Remote-PowerShell zum Erstellen der PvD in einem Ordner mit dem gleichen Namen wie die VM, aus dem sie erstellt wurde. Verwenden Sie Remote-PowerShell nicht mit CSV oder LocalStorage. VMM-Befehlsfehler werden vermieden, wenn zuerst das Verzeichnis und dann die leere Disk erstellt werden.
Führen Sie auf der Hyper-V-Maschine mkdir an dem Speicher aus.