22.8 System Center Virtual Machine Manager 2012

Servervirtualisierung bietet deutliche Vorteile in der Administration – so weit die weit verbreitete Meinung, die ich übrigens auch voll und ganz teile. Es ist nun aber so, dass die Servervirtualisierung einige neue Aufgabenstellungen beinhaltet, insbesondere in mittleren und großen Umgebungen.

Hier setzt der System Center Virtual Machine Manager 2012 an, der eine Art »zentrale Management-Anwendung« für die gesamte Virtualisierungsumgebung ist.

Man kann den Virtual Machine Manager vom Ansatz her grob mit VMware Virtual Center vergleichen, das ebenfalls als Management-Anwendung für die virtuelle Gesamtumgebung konzipiert ist.

22.8.1 Aufbau und Architektur

Das Gesamtsystem Virtual Machine Manager 2012 (ab jetzt kurz als VMM bezeichnet) besteht aus mehreren Komponenten, deren Zusammenspiel auf Abbildung 22.89 annähernd visualisiert ist:

• Der VMM selbst besteht aus mehreren Komponenten, die auf Wunsch auf einem Server installiert werden können. Zu nennen sind hier eine Datenbank, der eigentliche SCVMM-Dienst, die Administratorkonsole und optional ein Webinterface. Auf Wunsch können diese Dienste über mehrere Systeme verteilt werden, für sehr große Umgebungen (mehr als 150 physikalische Hosts) können auch mehrere VMM-Server eingesetzt werden.
• Verwaltet werden zunächst die Servervirtualisierungs-Hostsysteme. Neben den hauseigenen Systemen, also Virtual Server und Hyper-V, können Systeme von VMware verwaltet werden; ein VMware-Virtual-Center-Server muss dazu eingebunden werden.
• Viele Unternehmen setzen für das Monitoring der Umgebung den System Center Operations Manager 2012 (SCOM) ein. VMM kann mit diesem zusammenarbeiten und Daten dorthin weiterleiten.
• Die VMM-Administratorkonsole kann zwar auf dem VMM-Server ausgeführt werden, besser ist es allerdings, wenn diese auf einem oder mehreren Admin-PCs installiert wird. Das Administrationswerkzeug kann problemlos von der VMM-CD installiert werden.
• Für Benutzer, die eigentlich keine Admins sind, aber trotzdem über »eigene« VMs verfügen, ist das Self-Service-Portal entwickelt worden. Das Self-Service-Portal ist eine webbasierte Anwendung, die beispielsweise gute Dienste leistet, wenn eine Gruppe von Entwicklern selbst die virtuellen Testmaschinen verwalten soll.

Abbildung 22.89 Die Komponenten einer VMM-Umgebung im Zusammenspiel (Self Service-Portal nicht mehr mit VMM 2012 SP1)

22.8.2 Installation

Die Installation des VMM ist nicht aufregend schwierig, allerdings ist nicht »nur« der eigentliche Server, es sind auch SQL Server, Agents für die Hyper-V und eventuell das Service-Portal separat zu installieren.

VMM-Server, Voraussetzungen

Bevor Sie die VMM-DVD einlegen und das Setup starten können, müssen einige »Vorarbeiten« erledigt werden.

SQL Server

Der VMM benötigt zum Speichern der Daten eine SQL Server-Datenbank – das ist so weit wohl nicht überraschend. Wie bei den anderen System Center 2012-Produkten muss auch hier die Sortierung auf SQL_Latin1_General_CP1_CI_AS eingestellt sein. Das ist nicht die Standardeinstellung.

Falls Sie die System Center-Datenbanken auf einen SQL Server, der auch andere Datenbanken hostet, legen möchten, müssen Sie also eine separate Instanz einrichten und im Assistenten zur deren Installation die Sortierung anpassen (Abbildung 22.90).

Abbildung 22.90 Für den VMM muss die Sortierung angepasst werden.

Ich empfehle ohnehin, Datenbanken für unterschiedliche Anwendungsgruppen (z. B. ERP, System Center, SharePoint etc.) in verschiedene Instanzen zu installieren. In diesem Fall müssen Sie dies tun, da innerhalb einer Instanz keine unterschiedlichen Sortierungen für die Datenbanken möglich sind. Installieren Sie also eine SQL Server-Instanz für VMM (und gegebenenfalls andere System Center-Produkte).

Softwarevoraussetzungen

Auf dem zukünftigen VMM-Server gibt es eine Voraussetzung, um installieren zu können, die sich als recht zeitaufwendig erweisen wird, sofern Sie nicht über eine wirklich schnelle Internetanbindung verfügen. Die Rede ist vom ADK, dem Windows Assessment and Deployment Kit. Abbildung 22.91 zeigt eine Suchhilfe für das Microsoft Download Center. VMM kann auch für das automatisierte Installieren von Betriebssystemen verwendet werden, dazu wird das ADK in Teilen benötigt.

Die Installation des ADK ist recht simpel:

• Der Download aus dem Download Center ist nur harmlose 1,2 MByte groß.

  

  Abbildung 22.91 Das ADK kann im Download Center heruntergeladen werden.

• Es startet ein Installationsassistent, der sich in erster Linie für das Installationsverzeichnis interessiert (Abbildung 22.92).

  

  Abbildung 22.92 Die Installation erfolgt im Standardpfad.

• Auf der nächsten Dialogseite können Sie die zu installierenden Features auswählen. Für die Verwendung mit dem VMM benötigen Sie nicht alle Features, sondern nur die auf Abbildung 22.93 gezeigten.
• Der Installationsassistent wird nun erst den Download durchführen, anschließend die Installation – und dann ist es fertig!

  

  Abbildung 22.93 Diese beiden Optionen müssen Sie auswählen.

VMM-Server

Sobald die SQL Server-Instanz und die Voraussetzungen installiert sind, können Sie mit der Installation loslegen. Auf dem Splashscreen wählen Sie aus den diversen Möglichkeiten erwartungsgemäß den Punkt Installieren (Abbildung 22.94).

Zunächst müssen Sie entscheiden, was Sie installieren möchten (Abbildung 22.95). In diesem Fall benötigen wir den VMM-Verwaltungsserver, diese Installationsoption schließt die VMM-Konsole ein. Die Möglichkeit, nur die VMM-Konsole zu installieren, wird benötigt, wenn Sie Ihren Admin-PC damit ausrüsten möchten.

Auf der folgenden Dialogseite geht es um den Product Key, ohne den sich die Software nicht installieren lässt (ohne Abbildung). Weiterhin wird der Installationspfad abgefragt. Ich bin immer dafür, Standardpfade zu verwenden. Produktive Daten werden hier ohnehin nicht gespeichert (Abbildung 22.96).

Abbildung 22.94 Der Splashscreen der Installation

Abbildung 22.95 Installiert werden soll der »VMM-Verwaltungsserver«.

Abbildung 22.96 Ich empfehle die Übernahme des Standardpfads.

Auf Abbildung 22.97 wird es zum ersten Mal wirklich spannend, es geht um die Verbindung zur Datenbank:

• Die Angabe des Servernamens ist nun nicht die große Hürde. Auch wenn Sie eine benannte Instanz vorbereitetet haben, geben Sie hier nur den Servernamen ein und nicht zusätzlich den Instanznamen.
• Sofern Sie für den SQL Server die Standardportkonfiguration verwenden, können Sie die Textbox Port leer lassen.
• Wenn Sie keine Anmeldeinformationen angeben, erfolgt die Anmeldung an der Datenbank mit dem Dienstkonto des VMM-Servers, in vielen Fällen wird das das Computerkonto des VMM-Servers sein. Sie können das übrigens nachvollziehen, wenn Sie die Berechtigungen auf die Datenbank im SQL Server Management Studio kontrollieren.
• Die nächste Konfigurationsoption ist die Auswahl der Instanz. Die auf dem oben angegebenen SQL Server vorhandenen Instanzen sollten in der Dropdown-Liste angezeigt werden.
• Vermutlich werden Sie eine neue Datenbank anlegen. Name ist egal, ich würde es trotzdem beim Standardnamen belassen.

  

  Abbildung 22.97 Bei der Datenbankkonfiguration muss bereits eine SQL Server-Instanz mit der richtigen Sortierreihenfolge vorhanden sein.

Der auf Abbildung 22.98 gezeigte Dialog bietet zwei Einstellungsmöglichkeiten:

• Das Dienstkonto für den VMM-Server: Sie können den VMM-Dienst entweder als Lokales Systemkonto ausführen oder ein Domänenkonto dafür angeben. Funktioniert beides – bei einer hochverfügbaren Installation (mit zwei oder mehr VMM-Servern) müssen Sie ein Domänenkonto angeben.
• Ähnliches gilt für den Verschlüsselungsschlüssel: Man kann ihn auf dem lokalen Server speichern. Sofern mehrere VMM-Server im Spiel sind, müssen Sie ihn im Active Directory speichern. Sie geben dann einen LDAP-Pfad an.

Auf der folgenden Dialogseite (Abbildung 22.99) gibt es mit den Portnummern, die VMM verwenden soll, eine ganze Menge einzustellen. Die gute Nachricht: Im Normalfall können Sie diese Voreinstellungen einfach übernehmen.

Der nächste zu konfigurierende Aspekt ist die Bibliothekskonfiguration. Es wird eine Freigabe benötigt, in der VMM beispielsweise Vorlagen speichert. Auf Abbildung 22.100 ist zu sehen, dass der Assistent eine Freigabe anlegen kann – praktisch, schnell, unkompliziert. Sofern vorhanden, kann auch eine bestehende Freigabe verwendet werden.

Abbildung 22.98 Die Auswahl des Dienstkontos

Abbildung 22.99 Die »Portkonfiguration« kann im Normalfall übernommen werden.

Abbildung 22.100 Für die VMM-Bibliothek wird eine Freigabe benötigt.

Bevor die Installation startet, gibt es zunächst eine Installationszusammenfassung. Kontrollieren Sie nochmals diese Einstellungen, und starten Sie die Installation, die unproblematisch verlaufen dürfte (Abbildung 22.101).

Abbildung 22.101 Noch einmal kontrollieren – dann geht’s los.

Abbildung 22.102 zeigt, wie es nach der Installation aussehen sollte. Ergebnis: Die Software ist auf dem Server, die Datenbank ist eingerichtet, und die VMM-Konsole kann gestartet werden. Genau das zu tun, ist der nächste Schritt, denn nun müssen die Agents auf die zu verwaltenden Hyper-V-Server gebracht werden.

Abbildung 22.102 Optimalerweise sollte das Ergebnis so aussehen.

Agents installieren

Der VMM-Server ist nur eine Komponente des Gesamtsystems. Verwaltet werden sollen die vorhandenen Hyper-V-Server, die noch mit Agents ausgestattet werden müssen. Die Agents lassen sich per Push-Verfahren von der VMM-Konsole installieren, sodass sich auch bei einer größeren Menge von Hyper-V-Servern der Aufwand in Grenzen hält.

Der Startpunkt für die Agent-Installation wird in Abbildung 22.103 gezeigt:

• Rufen Sie die Kategorie Fabric auf.
• Wählen Sie im Ribbon Ressoucen hinzufügen · Hyper-V-Hosts und -Cluster.

Wer die Vorgängerversion, also VMM 2008 R2, kennt, wird bemerken, dass es hier wesentlich mehr Komponenten gibt, die hinzugefügt werden können. VMM hat sich in den letzten Jahren von einer einfachen zentralen Hyper-V-Konsole zu einem durchaus funktional anspruchsvollen Werkzeug für die Verwaltung einer virtuellen Umgebung entwickelt.

Abbildung 22.103 Das Installieren der Agents auf Hyper-V-Hosts beginnt hier.

Das Hinzufügen eines Hyper-V-Servers wird erwartungsgemäß mithilfe eines Assistenten durchgeführt. Die erste Frage stellt sich nach dem Speicherort des Servers, wobei es hier um die Zugehörigkeit zu einer Domäne geht. Die am häufigsten genutzte Option wird ein Server in einer vertrauenswürdigen AD-Domäne sein, daher führe ich genau diesen Fall vor. Bei Servern, die in der DMZ stehen, sind zusätzliche Konfigurationsschritte erforderlich – zum einen für die Agent-Installation, zum anderen müssen auch die auf Abbildung 22.99 konfigurierten Ports in der Firewall geöffnet werden – zumindest teilweise.

Die Installation des Agent muss mit einem Konto, das auf dem Zielserver administrative Berechtigungen hat, ausgeführt werden. Sie können in dem Dialog (Abbildung 22.105) entweder ein hinterlegtes Konto (Vorhandenes ausführendes Konto verwenden) auswählen oder Anmeldeinformationen manuell eingeben.

Der Dialog zur Auswahl eines ausführenden Kontos ist auf Abbildung 22.106 zu sehen. Hier kann ein bereits hinterlegtes Konto ausgewählt oder auch ein neues angelegt werden.

Der im Bild angelegte Domänen-Admin ist in der Praxis übrigens keine so brillante Idee: Klar, damit geht alles, aber das Konto ist für so etwas tabu. Im Bild ist es nur eine Testumgebung. Denken Sie aber daran, dass das zur Agent-Installation verwendete Konto auf den Zielmaschinen lokaler Admin sein muss.

Abbildung 22.104 Zumeist dürften die zu verwaltenden Server Domänenmitglieder sein.

Abbildung 22.105 Das Konto, das die Installation ausführt, muss lokaler Admin auf den Zielmaschinen sein.

Abbildung 22.106 Optimalerweise arbeiten Sie mit einem vordefinierten Konto (Domänen-Admin muss nicht sein).

Abbildung 22.107 zeigt, wie die mit dem Agent auszustattenden Hyper-V-Server gesucht werden können: entweder einen Namen angeben (pro Zeile einen Namen) oder eine AD-Abfrage formulieren. Die Existenz der gewählten Maschinen wird auf Abbildung 22.108 bestätigt, wo Sie auch auswählen können, wo dann wirklich der Agent drauf soll.

Abbildung 22.107 Geben Sie hier die Maschinen an, auf denen der Agent installiert werden soll.

Abbildung 22.108 Die Server sollten hier erkannt worden sein.

Der nächste Dialog (Abbildung 22.109) stellt einige generelle Aspekte ein:

• Entscheiden Sie, in welche Hostgruppe die neuen Hyper-V-Hosts aufgenommen werden sollen. Mit Hostgruppen kann die Umgebung einerseits etwas »sortiert« werden, andererseits können damit Einstellungen vorgenommen und Berechtigungen erteilt werden.
• Falls der Hyper-V-Host bereits zu einer anderen VMM-Umgebung gehört, kann er der neuen Umgebung zugewiesen werden.
• Weiterhin können Sie optional Standardpfade für die auf dem Hyper-V-Host neu anzulegenden virtuellen Maschinen angeben.

  

  Abbildung 22.109 Sie können hier die Hostgruppe, der die Maschine zugeordnet werden soll, auswählen.

Den in Abbildung 22.110 gezeigten Dialog werden Sie nur sehen, wenn Sie Agents auf Hyper-V-2012-Servern installieren. Hier legen Sie einige Einstellungen für Livemigrationen fest. Die Einstellungen sind so weit selbsterklärend.

Abbildung 22.110 Aktivieren und limitieren Sie Livemigrationen.

Abbildung 22.111 Dieses Ergebnis ist das auf Maschinen mit lokalen Platten erwartete.

Die Installation der Agents wird einige Minuten dauern. Auch nach erfolgreichem Abschluss wird auf Maschinen ohne aktiviertes Multipfad-E/A (braucht man in Umgebungen mit redundanten Pfaden zu SAN-Storage-Systemen) die auf Abbildung 22.111 gezeigte Warnung erscheinen. Diese kann ignoriert werden – solange Sie nicht wirklich eine pfadredundante SAN-Umgebung betreiben und das Multipathing zu aktivieren vergessen haben.

Agents der Vorversion upgraden

Die Wahrscheinlichkeit ist durchaus gegeben, dass Sie bereits eine Vorgängerversion von Hyper-V im Einsatz haben, die mit der Vorgängerversion von VMM gemanagt wird. Daraus ergeben sich die Fragen, ob VMM 2012 auch frühere Hyper-V-Versionen verwalten kann und wie man diese an den neuen VMM bekommt.

Erste Antwort: Klar kann der VMM 2012 auch ältere Hyper-V-Versionen verwalten. Der Beweis ist auf Abbildung 22.112 zu sehen – die Hyper-V Server 2008 R2 werden vom Hinzufüge-Assistenten erkannt.

Abbildung 22.112 Hyper-V Server 2008 R2 werden gefunden.

In dem hier gezeigten Fall ist auf den Hyper-V-Hosts jeweils der VMM 2008-Agent installiert. Wie Abbildung 22.113 zeigt, gibt es eine Fehlermeldung, wenn Sie versuchen, den neuen Agent einfach über einen Agent der Vorversion »drüberzuinstallieren«. Schlechte Nachrichten also, Sie müssen zunächst eine manuelle Deinstallation durchführen. Abbildung 22.114 zeigt, dass es sich um eine ganz normale Deinstallation auf dem Hyper-V-Host handelt. Lästig zwar, wenn Sie Dutzende Hosts haben, aber technisch kein Problem.

Abbildung 22.113 Ein direktes Upgrade des Agent von VMM 2008 ist leider nicht möglich.

Abbildung 22.114 Der alte Agent kann deinstalliert werden.

Ist die Deinstallation erledigt, können Sie die VMM 2012-Agent-Installation einfach noch mal starten – und dann sollte sie erfolgreich sein.

VMM-Konsole auf Admin-PC installieren

Ich bin nun bekanntermaßen kein Fan davon, sich zur Administration auf Servern anzumelden. Solche Aufgaben sollten die Admins bitte auf den Admin-PCs ausführen und nicht ständig per RDP auf den Servern hängen. Dies gilt natürlich auch für die Arbeit mit dem Virtual Machine Manager. Die Frage ist also, wie man die VMM-Konsole auf dem viel gerühmten Admin-PC installiert. Die Antwort ist schnell gegeben:

• Legen Sie den VMM-Installationsdatenträger auf dem Client ein und starten Sie die Installation.
• Im Dialog Funktionen zur Installation auswählen entscheiden Sie sich für die VMM-Konsole (Abbildung 22.115).

Die Installation sollte ohne weitere Überraschungen ablaufen.

Abbildung 22.115 Auf dem Admin-PC installieren Sie nur die Konsole.

Wenn die VMM-Konsole erstmalig gestartet wird, werden Sie gefragt, mit welchem VMM-Server eine Verbindung aufgebaut werden soll (Abbildung 22.116). Mehr als den Namen einzugeben (gefolgt von der Portnummer), brauchen Sie nicht zu tun, eventuell müssen alternative Anmeldeinformationen hinterlegt werden.

Abbildung 22.116 Beim Start der Konsole muss der VMM-Server, mit dem eine Verbindung aufgebaut werden soll, angegeben werden.

22.8.3 Schnellüberblick

In diesem Schnellüberblick möchte ich Ihnen ein erstes »Gefühl« für den Virtual Maschine Manager vermitteln.

Hosts verwalten

Die erste Ansicht des VMM ist die Hosts-Ansicht, also diejenige, die sich mit den physikalischen Systemen beschäftigt. Abbildung 22.117 zeigt diese Ansicht in einer bescheidenen Umgebung mit sechs Hosts. In größeren Umgebungen mit mehreren Dutzend Hosts ist es im Allgemeinen angenehm, mit Filtern zu arbeiten; diese können im linken Bereich der Anwendung per Mausklick definiert werden.

Zum selektierten Host werden etliche Parameter angezeigt; weiterhin gibt es ein Kontextmenü namens Einstellungen, das im Wesentlichen dieselben Konfigurationsarbeiten wie der Hyper-V-Manager ermöglicht.

Weiterhin können zusätzliche Hostgruppen definiert werden. Diese erfüllen zwei Aufgaben:

• Einerseits kann in großen Umgebungen etwas »Ordnung« in die unter Umständen sehr lange Liste von vorhandenen Hosts gebracht werden.
• Andererseits können die Hostgruppen zur Beschränkung des Zugriffs verwendet werden.

  

  Abbildung 22.117 Alle konfigurierten Hosts sieht man in dieser Ansicht.

Auf den Hostsystemen (zumindest auf den Windows Server-basierten) wird ein Agent installiert; bei Hosts, die Mitglied einer vertrauenswürdigen Domäne sind, kann diese Installation von der VMM-Konsole initiiert werden. Im Allgemeinen funktioniert das schnell und unproblematisch.

Virtuelle Maschinen verwalten

Die vermutlich wichtigste Funktionalität sehen Sie in Abbildung 22.118, nämlich die Verwaltung der virtuellen Maschinen. Diese können überwacht, gestartet, angehalten, verschoben und konfiguriert werden. Weiterhin ist das Anlegen neuer Maschinen und das Konvertieren von »fremden« VMs oder physikalischen Maschinen möglich. Dies werde ich Ihnen später noch vorführen.

Für das Anlegen und Konfigurieren von virtuellen Maschinen haben Sie dieselben Möglichkeiten wie mit dem Hyper-V-Manager; zusätzlich steht Ihnen die Nutzung von Vorlagen offen.

Die VMM-Admin-Konsole verfügt über eine eigene Anzeigeapplikation, um auf die virtuellen Maschinen »schauen« zu können. Diese bietet etwas weniger Möglichkeiten als die des Hyper-V-Managers, funktioniert aber ansonsten genauso gut.

Abbildung 22.118 Bei der Verwaltung der virtuelle Maschinen spielt es keine Rolle, auf welchem Server diese tatsächlich ausgeführt werden.

Bibliotheken

Administratoren haben im Allgemeinen wenig Zeit und sind daher gezwungen, möglichst viel Effizienz in die tägliche Arbeit zu bringen. Eine der Möglichkeiten dazu bietet die Arbeit mit Vorlagen.

Die Vorlagen gehören zum Bereich Bibliothek, der auf Abbildung 22.119 zu sehen ist. Bibliothekserver können beispielsweise die Server sein, auf denen VMM 2012 ausgeführt wird, es kann auch ein »normaler« Windows-Dateiserver sein, auf dem der VMM-Agent installiert wird. Dort wird eine Freigabe (oder auch mehrere) als Bibliotheksfreigabe ausgewählt.

In der Ribbonleiste der Virtual Machine Manager-Applikation finden Sie verschiedene Bereiche mit Menüpunkten zum Erstellen von Vorlagen, Hardwareprofilen und dergleichen mehr. Auf der Abbildung ist auch die Schaltfläche für das Importieren einer Vorlage zu sehen.

Abbildung 22.119 Bibliotheken speichern Vorlagen, virtuelle Festplatten und komplette virtuelle Computer.

Ein wenig später in diesem Kapitel möchte ich Ihnen einen kurzen Überblick über die Verwendung der Vorlagen geben. Man könnte wesentlich mehr Details aufzeigen, Ziel ist hier aber eine kurze Einführung, die Lust machen soll, selbst weitere Möglichkeiten zu entdecken.

22.8.4 Virtuelle Maschine anlegen

Eine der naheliegendsten Aufgaben ist das Anlegen von neuen virtuellen Maschinen. Im Ribbon findet sich der entsprechende Menüpunkt (Abbildung 22.120), der einen Assistenten startet. Die hier angelegte virtuelle Maschine wird zwar im Allgemeinen direkt auf einem Server gestartet, alternativ kann man sie allerdings auch zunächst in einer Bibliothek anlegen und später auf einem dann auszuwählenden Host starten.

Abbildung 22.120 Hier beginnt das Anlegen einer neuen virtuellen Maschine.

Die Startfrage des Assistenten dreht sich darum, ob die neue virtuelle Maschine von einer irgendwie gearteten Vorlage (bestehenden virtuellen Maschine, VM-Vorlage oder bestehenden Festplatte) erstellt oder ob eine neue Maschine mit leerer Festplatte erzeugt werden soll (Abbildung 22.121). Das Erstellen einer »richtigen« Vorlage werde ich ein wenig später ausführlich vorführen.

Abbildung 22.121 Die erste Seite des Assistenten: Vorlage oder nicht?

Selbstverständlich kann man auch einfach eine bestehende virtuelle Maschine auswählen, nach Klick auf Durchsuchen gelangen Sie zu einem Auswahldialog, der die virtuellen Maschinen, die nicht ausgeführt werden, zur Auswahl anbietet. Wenn die virtuelle Maschine mit Windows-Betriebssystem läuft, ist das allerdings nur eine begrenzt gute Idee: Eine Windows-Installation muss mittels Sysprep »verallgemeinert« werden, bevor sie als anderes System verwendet werden kann. Vielleicht kennen Sie das Verfahren von der Installation von Clientsystemen – bei Servern gilt das natürlich ebenso. Unter anderem wird dabei der Betriebssysteminstanz eine andere SID zugeordnet. Für diese Demo entscheiden wir uns also für das Erstellen einer neuen virtuellen Maschine mit leerer Festplatte.

Die zweite Entscheidung, die der Assistent von Ihnen verlangt, ist der Name der zukünftigen virtuellen Maschine (Abbildung 22.122). Das ist nun wirklich nicht spektakulär, bietet aber Raum für ein paar Anmerkungen:

• Ich installiere hier zunächst eine virtuelle Maschine komplett »per Hand«. Demnach wird der hier eingetragene Name nicht automatisch als Betriebssystemname der VM übernommen. Wenn wir später mit Vorlagen arbeiten, wird das aber der Fall sein. Zunächst gilt hier, dass der an dieser Stelle vergebene Name und der reale Name der VM unterschiedlich sein können.
• Vielleicht ist Ihnen in Abbildung 22.122 aufgefallen, dass im Namen ein Master vorhanden ist. Hintergrund ist, dass ich hier in der Tat zunächst eine leere Maschine installiere, die ich dann klonen und als Master für die Erstellung einer Vorlage verwenden will. Die VM will ich also irgendwann später als Master verwenden, die Installation an sich hat aber mit der späteren »Master-Werdung« nichts zu tun – nur um Missverständnissen vorzubeugen.

Abbildung 22.122 Fängt langsam an: Ein Name muss für die virtuelle Maschine gewählt werden.

Auf Abbildung 22.123 sehen Sie den Dialog zur Konfiguration der Hardware der neuen virtuellen Maschine. Das ist alles im Grunde genommen nicht wirklich überraschend, erwähnenswert ist allerdings die Auswahl des Installationsmediums – im Allgemeinen wird man hier eine ISO-Datei auswählen wollen. Der Auswahldialog für die ISO-Datei wird auf Abbildung 22.124 gezeigt. Spannender als die Auflistung der vorhandenen Images ist die Frage, wie die ISO-Files überhaupt in die Bibliothek kommen – der folgende Kasten gibt die entsprechende Antwort.

Abbildung 22.123 Konfiguration der Hardware; erwähnenswert ist hier vor allem die Auswahl des Installationsmediums.

Abbildung 22.124 Bei der Auswahl des Installationsmedium wird in der Bibliothek gesucht.

Auf der nächsten Dialogseite geht es um die Frage, wo die entstehende virtuelle Maschine gespeichert oder bereitgestellt werden soll (Abbildung 22.126). Neben der in meinem Testsystem nicht vorhandenen Option der privaten Cloud kann die VM auf einem Hyper-V-Host oder in der Bibliothek gespeichert werden. Wenn Sie die Maschine sofort verwenden möchten, was im Allgemeinen wohl der Fall ist, kommt die Bibliothek allerdings nicht infrage: Von dort kann sie nicht ausgeführt, sondern muss zuerst auf einem Host oder in der privaten Cloud bereitgestellt werden.

Abbildung 22.126 Wo soll die neue VM bereitgestellt werden?

Abbildung 22.127 zeigt den Dialog zur Auswahl des Ziel-Hyper-V-Hosts für die neue virtuelle Maschine. Mit einer »Sternchen-Bewertung« gibt es eine Empfehlung für die Platzierung – letztendlich entscheiden aber Sie, wo die VM laufen soll. Im unteren Bereich des Dialogs gibt’s auch eine Erklärung der Bewertung, was eventuell ganz interessant ist.

Die eigentliche (Hardware-)Konfiguration der virtuellen Maschine haben Sie zu diesem Zeitpunkt schon erledigt – das wurde weiter oben auch gezeigt. Was fehlt, sind die Einstellungen für die virtuelle Maschine bezüglich des Hyper-V-Servers, auf dem sie nun erzeugt wird. Hierzu gibt es zwei Dialoge:

• Den ersten Dialog zeigt Abbildung 22.128. Hier geht es im Wesentlichen um den Speicherort (vorbelegt ist der Standardpfad) und den virtuellen Switch, mit dem die VM verbunden werden soll.
• Abbildung 22.129 behandelt vor allem die Einstellungen für Start und Stopp der VM. Weiterhin können Sie hier das zu installierende Betriebssystem angeben.

Abbildung 22.127 Auswahl des Hosts für die neue virtuelle Maschine

Abbildung 22.128 Hostspezifische Einstellungen werden hier vorgenommen.

Abbildung 22.129 In diesem Dialog werden letzte Einstellungen getroffen.

Sind alle Einstellungen gemacht, erstellt der VMM einige Aufträge, die zur Erzeugung der neuen VM abgearbeitet werden. Die Abarbeitung übernimmt natürlich der VMM selbst, der seine Aktivitäten über Aufgaben, die in Aufgabenwarteschlangen erzeugt werden, steuert. Das in Abbildung 22.130 gezeigte Fenster öffnet sich automatisch, Sie können es aber auch schließen – es sei denn, Sie schauen gern dabei zu, wie der VMM für Sie arbeitet.

Abbildung 22.130 Für die Erstellung der VM werden einige Aufträge erzeugt, die der VMM abarbeitet.

Nach Abarbeitung der Aufgaben sollte die VM ohne irgendwelche Fehlermeldungen angelegt worden sein. Das sieht dann in etwa so wie auf Abbildung 22.131 gezeigt aus. Ob die VM nach Abschluss gestartet wird oder nicht, hängt von der Einstellung ab, die in dem auf Abbildung 22.129 gezeigten Dialog getroffen wurde.

Abbildung 22.131 Die VM ist angelegt und kann nun gestartet werden.

Abbildung 22.132 Kurze Kontrolle: Im Hyper-V-Manager taucht die neue VM natürlich auch auf. Das ISO-Image ist übrigens aus der Bibliothek in den VM-Ordner kopiert worden.

Abbildung 22.132 zeigt eine kleine Kontrolle mit dem Hyper-V-Manager, der ja standardmäßig auf jedem Hyper-V-Host vorhanden ist. Erwartungsgemäß ist die VM mit den konfigurierten Einstellungen angelegt worden, was ja auch nicht so dramatisch überraschend ist. Interessant ist aber, dass das ISO-Image aus der Bibliothek in das VM-Verzeichnis kopiert worden ist. Wenn Sie das nicht möchten, sind zusätzliche Arbeiten notwendig, insbesondere muss beim Konfigurieren der Hardwareressourcen der entsprechende Haken zur gemeinsamen Nutzung gesetzt sein (Abbildung 22.123).

Ist die virtuelle Maschine gestartet, wird sie von dem ISO-Image booten und installiert das Betriebssystem. Im nun folgenden Abschnitt zeige ich Ihnen, wie man aus der virtuellen Maschine eine Vorlage erstellt und diese dann anwendet.

22.8.5 Virtuelle Maschine aus Vorlage erzeugen

Das Erzeugen einer Vorlage aus einer virtuellen Maschine ist eigentlich simpel: Im Kontextmenü einer nicht ausgeführten virtuellen Maschine gibt es den Menüpunkt Erstellen · VM-Vorlage erstellen (Abbildung 22.133).

Abbildung 22.133 Im Kontextmenü der ausgeschalteten VM findet sich der Menüpunkt zum Erstellen der VM-Vorlage.

Sieht eigentlich recht einfach aus, wäre da nicht die auf Abbildung 22.134 gezeigte Meldung, die darauf hinweist, dass der Vorgang die als Vorlage zu erstellende virtuelle Maschine beschädigt.

Was passiert da?

• Wenn das Betriebssystem der virtuellen Maschine ein Windows-Betriebssystem ist, kann man es guten Gewissens nicht einfach vervielfältigen. Vielmehr muss man dafür sorgen, dass die entstehende Kopie eine unique Betriebssysteminstanz ist, die neben einem eigenen Namen beispielsweise auch eine eigene SID hat.
• Nun geht man so vor, dass man die Kopiervorlage (bzw. VM-Vorlage) generalisiert, was man mit sysprep.exe (Bestandteil der Betriebssysteme) mit wenigen Mausklicks erledigen kann. Dabei wird die Installation etwas verändert (und somit, wenn man so will, »beschädigt«).
• Wenn eine generalisierte Betriebssysteminstanz startet, ist das so, als würde ein völlig neues Betriebssystem starten, was bedeutet, dass unter anderem der Rechnername und die SID neu vergeben werden und wirklich eine unique Betriebssysteminstanz vorliegt.

Abbildung 22.134 Wichtige Warnung! Das Erstellen der VM-Vorlage ist »ein wenig destruktiv«.

Wenn der VMM eine virtuelle Maschine als Vorlage speichert, generalisiert (»gesysprepped«) er die VM zunächst und speichert diese Version als Vorlage. Grundsätzlich alles richtig – bis darauf, dass die virtuelle Maschine rein formal gesehen eine andere wird.

Der mögliche Lösungsweg wird von der Warnmeldung auch direkt mitgeliefert:

• erst einen Klon erstellen,
• diesen dann als Vorlage speichern, und
• dann machen wir das mal so:

Klon erstellen

Das Erstellen eines Klons wird wie weiter oben auf Abbildung 22.133 gezeigt initiiert und ist nur mit ausgeschalteten VMs möglich. Der Klonvorgang wird mittels eines Assistenten vorbereitet, dessen erste Seite Abbildung 22.135 zeigt. Auf der linken Seite des Dialogs ist zu erkennen, dass diverse Punkte abgefragt werden, die vergleichbar mit dem Anlegen einer neuen VM sind – sie werden daher hier nicht nochmals besprochen.

Abbildung 22.135 Beim Erzeugen des Klons werden etliche Einstellungen abgefragt.

Den laufenden Klonvorgang können Sie im Auftragsfenster verfolgen, wie man auf Abbildung 22.136 sieht, sind hier diverse Schritte abzuarbeiten – der Admin kann sich allerdings bequem zurücklehnen und braucht nur abzuwarten, bis er fertig ist.

Es ist denkbar, dass der Klonvorgang mit einer Fehlermeldung abbricht, beachten Sie dann bitte den folgenden Kasten.

Abbildung 22.136 Die Erstellung des Klons zieht sich über mehrere Schritte.

Vorlage erstellen

Wenn nun der Klon erstellt worden ist, können Sie daraus eine VM-Vorlage erstellen. Los geht’s im Kontextmenü des Klons, der natürlich bei der Vorlagenerstellung nicht ausgeführt werden darf (Abbildung 22.138).

Abbildung 22.138 Nun also los: »VM-Vorlage erstellen«!

Der Assistent zum Erstellen der Vorlage führt Sie durch mehrere Dialoge. Neben der wenig überraschenden Hardwarekonfiguration (ohne Abbildung, da dem Sinne nach bekannt) gibt es einen Dialog namens Gastbetriebssystem konfigurieren (Abbildung 22.139, Abbildung 22.140). Hier finden sich einige nicht uninteressante Aspekte:

• Standardmäßig wird der Computername so gesetzt, wie der Name der virtuellen Maschine lautet.
• Es kann ein Kennwort für das lokale Admin-Konto vorgegeben werden (Abbildung 22.139).
• Sie können den zu verwendenden Product Key vergeben. Nehmen Sie diese Einstellung vor! Die VM wird sonst beim ersten Start genau an dieser Stelle stehen bleiben.
• Rollen und Funktionen können installiert werden, sofern das nicht ohnehin in der »Quell-VM« gemacht worden ist.
• Interessant ist mit Sicherheit auch die Möglichkeit, die VM direkt einer Domäne beitreten zu lassen. Hierzu können Sie in der entsprechenden Rubrik einige Einstellungen vornehmen (Abbildung 22.140).

Abbildung 22.139 Diverse Einstellungen für das aus der Vorlage zu erzeugende Gastbetriebssystem.

Abbildung 22.140 Hier wird festgelegt, welches Konto den Beitritt zur Domäne durchführen soll.

Im nächsten Schritt können Sie den Bibliothekserver, auf dem die Vorlage gespeichert werden soll, auswählen. In meiner auf Abbildung 22.141 gezeigter Testumgebung habe ich lediglich einen Bibliothekserver; sind mehrere vorhanden, ist auch die Bewertung zum Ermitteln des am besten geeigneten Bibliothekservers sinnvoll. Im letzten Dialog des Assistenten muss nun lediglich noch der Pfad für die Vorlage auf dem Bibliothekserver festgelegt werden. Wie Abbildung 22.142 zeigt, geben Sie hier das Basisverzeichnis an; ein Klick auf Durchsuchen hilft.

Wie im VMM üblich, werden Aufträge erstellt, die dann abgearbeitet werden. Abbildung 22.143 zeigt einen interessanten »Zwischenzustand« während der Verarbeitung: Sie sehen, dass die Vorlagen-VM mit Sysprep behandelt wird. Im Detail passiert hier Folgendes: Der VMM fährt die virtuelle Maschine hoch, führt Sysprep aus und fährt die Maschine wieder herunter. Die VM und somit die darauf basierende Vorlage sind jetzt verallgemeinert – die VM ist dann, wie auf der Warnmeldung angegeben (Abbildung 22.134), »zerstört«, zumindest befindet sie sich nicht mehr im Ursprungszustand und verhält sich betriebssystemmäßig wie eine neu installierte Betriebssysteminstanz (zumindest bezüglich Computername und SID).

Abbildung 22.141 Auswahl des Bibliothekservers

Abbildung 22.142 Der Pfad, unter dem die virtuelle Maschine auf dem Bibliothekserver gespeichert wird

Abbildung 22.143 Hier wird die als Vorlage dienende Maschine »gesysprepped«.

VM erstellen

Nun kommt der Moment, für den wir das alles getan haben: das Erzeugen einer neuen VM aus der soeben mit mehr oder weniger viel Mühe erstellten Vorlage.

Das Erzeugen einer fertigen VM geht so angenehm und zügig vonstatten, dass dem geneigten Admin wieder deutlich vor Augen geführt wird, warum er eine komfortable Virtualisierungslösung haben wollte.

Der erste Schritt ist das Starten des Assistenten mit Virtuelle Maschine erstellen (Abbildung 22.144). Das ist übrigens derselbe Startpunkt wie immer, auch wenn Sie nicht mit Vorlagen arbeiten, beginnt das Erstellen einer neuen VM hier.

Abbildung 22.144 Das Erstellen einer virtuellen Maschine, auch aus einer Vorlage, beginnt genau hier.

Der entscheidende Moment kommt im ersten Dialog des Assistenten, in dem Sie wählen können, welche Vorlage verwendet werden soll. In der Rubrik Typ: VM-Vorlage sollte die zuvor erstellte VM vorhanden sein (Abbildung 22.145).

Abbildung 22.145 Die »VM-Vorlage« wird ausgewählt.

Der dann folgende (nicht abgebildete) Dialog fragt nach dem Namen der zu erstellenden VM. Dann wird es wieder interessanter, wenn es um die Hardwarekonfiguration geht (Abbildung 22.146). Hier werden Sie übrigens die Einstellungen der als Vorlage verwendeten VM finden. Interessant (und daher abgebildet) ist, dass bei der Festplatte ein Pfad auf den Bibliothekserver angegeben ist. Ist ja auch kein Wunder, immerhin ist diese sozusagen die »Basis« der neuen VM.

Beim Erstellen der neuen virtuellen Maschine ist der in Abbildung 22.147 gezeigte Dialog der spannendste:

• Im Abschnitt Identitätsinformationen wird der Computername hinterlegt, der dem Betriebssystem der neuen VM verpasst wird.
• Lokales Administratorkennwort und Domänenbeitritt werden im Normalfall bereits bei der Erstellung der Vorlage hinterlegt.
• Achten Sie drauf, einen Product Key für das Betriebssystem einzutragen. Wenn dieser nicht vorhanden ist, wird die Installation anhalten und auf die Eingabe des Schlüssels warten.

Abbildung 22.146 Die Hardwarekonfiguration, hier die virtuelle Festplatte, die vom Bibliothekserver geholt wird

Wenn alle Einstellungen vorgenommen sind, fängt der VMM an zu arbeiten, wie üblich werden Aufgaben erstellt, die abgearbeitet werden. Abbildung 22.148 zeigt, dass es jede Menge Schritte gibt, die zum Deployment erforderlich sind. Die gute Nachricht für jeden Admin ist, dass man außer abzuwarten nichts tun muss.

Die neue virtuelle Maschine wird in der Liste der vorhandenen VMs angezeigt, der Status ist Wird erstellt (Abbildung 22.149). Sie werden im Kontextmenü der VM sehen, dass zunächst etliche Optionen deaktiviert sind. Nach und nach werden die Optionen auswählbar, darunter auch Verbindung herstellen oder anzeigen · Verbindung herstellen über Konsole. Diese Funktion zeigt, wie der Name ja schon sagt, die Konsole, die man auch bei einer Installation auf Hardware sehen würde. Abbildung 22.150 stellt dar, wie das dann aussieht. Wenn die Installation an einem Punkt einfach »nicht vorangeht«, kann es nicht schaden, auf die Konsole zu schauen. Eventuell wartet ein Installationsschritt auf eine Benutzereingabe. Beispielsweise passiert das, wenn kein Product Key hinterlegt wurde.

Abbildung 22.147 Der Name der zukünftigen VM wird hier eingetragen. Achten Sie darauf, dass der »Product Key« angegeben ist.

Abbildung 22.148 VMM bei der Arbeit

Abbildung 22.149 Die virtuelle Maschine ist bereits in der Überblicksansicht zu sehen.

Abbildung 22.150 Im Verlauf der Installation kann man den VMM bei der Arbeit zusehen.

22.8.6 Virtuelle Maschinen verschieben

Gründe, eine virtuelle Maschine zwischen zwei Hyper-V-Hosts zu verschieben, gibt es einige, zum Beispiel:

• Ein Server soll ganz oder vorübergehend stillgelegt werden, beispielsweise wegen Wartungsarbeiten.
• Aus Performancegründen sollen die VMs anders verteilt werden.

Mit dem Basis-Hyper-V-Manager ist mittlerweile das Verschieben von VMs möglich, in der 2008 R2-Version ging das nur mit VMM, nicht mit dem Hyper-V-Manager. Mit dem VMM funktioniert es natürlich nach wie vor bequem per Mausklick, wobei aber unterschieden werden muss, ob zwischen zwei Hyper-V-2012-Servern verschoben wird oder ob auch ältere Versionen beteiligt sind:

Das Verschieben (= Migrieren) einer virtuellen Maschine startet, Überraschung, in deren Kontextmenü, wobei es zwei recht ähnliche Menüpunkte gibt (Abbildung 22.151):

• Virtuelle Maschine migrieren verschiebt eine virtuelle Maschine zwischen zwei Hyper-V-Hosts.
• Speicher migrieren verschiebt die virtuelle Maschine innerhalb eines Hyper-V-Hosts an einen anderen Speicherort. Nützlich ist das beispielsweise nach Plattenerweiterungen, wenn es weitere Laufwerke gibt.

Abbildung 22.151 Hier startet das Verschieben bzw. Migrieren der VM.

Wenn Sie die virtuelle Maschine migrieren wollen, wird ein Assistent abfragen, auf welchen Hosts diese verschoben werden soll. Auf Abbildung 22.152 sind einige Aspekte zu erkennen:

• Der in der Liste zuoberst aufgeführte Host ist ein Windows Server 2012-System. Als Transfertyp wird dort Live (VSM) angeboten.
• Der zweite Host in der Liste ist der aktuelle Host, ebenfalls ein 2012er. Hier wird Live Storage angeboten, also ein Verschieben des Plattenspeichers innerhalb des Hosts – ohne Unterbrechung.
• Die übrigen Hosts sind 2008 R2-Server, dort wird als Transfertyp nur Netzwerk angegeben, was mit einer Betriebsunterbrechung verbunden wäre.
• Meine Demoumgebung enthält keine SAN-Storage-Systeme, dort gäbe es noch einen weiteren Transfertyp.

Abbildung 22.152 Auswahl des Zielhosts

Wie Sie auf Abbildung 22.152 sehen können, erhalten Sie mit einem »Sternchen-System« Empfehlungen für die Platzierung der zu verschiebenden VM. Gut, es gibt einige Ausschlusskriterien, die zu null Sternen führen. Ansonsten wäre es natürlich mehr als sinnvoll, wenn die zu erwartende Last berücksichtigt würde. Nun ermittelt der VMM leider nicht die Lastdaten der vergangenen Tage oder Ähnliches. Der geneigte Admin hat aber die Möglichkeit, durch Klick auf die Schaltfläche Erwartete Auslastung (Abbildung 22.152) zu einem Dialog zu kommen, in dem man einige fundamentale Lastparameter eintragen kann. Die auf Abbildung 22.153 gezeigten Eingabemöglichkeiten sind zugegebenermaßen eher eine grobe Klassifizierung, für den Zweck der Auswahl eines passenden Hyper-V-Hosts reicht das aber voll und ganz.

Abbildung 22.153 Zur Verbesserung der Qualität der Empfehlungen kann man einige Angaben zur VM-Last vornehmen.

Es folgen zwei weitere Dialoge, um den Verschiebevorgang zu spezifizieren. Zunächst wird der Speicherort für die Konfigurationsdateien und VHDs auf dem Zielserver gewählt (Abbildung 22.154). Vorbelegt ist hier der Standardpfad – vielleicht möchten Sie die VM ja aber auch auf einem anderen Laufwerk platzieren.

Abbildung 22.154 Speicherort auf dem zukünftigen Host

Die zweite Einstellung betrifft die Netzwerkkonnektivität. Abbildung 22.155 zeigt den Dialog, der die Auswahl von VM-Netzwerk, virtuellem Switch und gegebenenfalls VLAN ermöglicht. Die VM soll ja schließlich an ihrer neuen Wirkungsstätte Zugriff auf das Netzwerk haben, insbesondere bei Livemigrationen, bei denen ja alles schön unterbrechungsfrei funktionieren soll. So wichtig die Einstellung ist – es ist nicht kompliziert.

Abbildung 22.155 Netzwerk und virtueller Switch nebst eventueller VLANs können auf dem Zielhost gewählt werden.

Zwischen zwei Windows 2012-Hyper-V-Hosts verschieben

Wirklich ein Vergnügen ist das Verschieben einer VM zwischen zwei Hyper-V 2012-Hosts. Auch ohne SAN-Infrastruktur wird eine laufende VM migriert. Abbildung 22.156 dokumentiert, dass die im Verschiebevorgang befindliche VM erreichbar bleibt. Livemigration funktionierte bei Hyper-V 2008 R2 zwar auch, allerdings nur mit SAN-Infrastruktur. 2012 bringt also dieses »Enterprise-Grade-Feature« auch in kostengünstiger mit lokalen Platten aufgebauter Umgebung.

Zu beachten ist, dass Livemigrationen nur funktionieren, wenn sie in den Hyper-V-Einstellungen auf den beteiligten Hosts zugelassen sind. Abbildung 22.157 zeigt den entsprechenden Dialog aus dem Hyper-V-Manager. Interessant ist auch die Möglichkeit, Livemigrationen über ein bestimmtes Netzwerksegment zu führen.

Abbildung 22.156 Während des Verschiebens läuft der Ping durch.

Abbildung 22.157 In den Hyper-V-Einstellungen müssen »Livemigrationen« zugelassen sein.

Gemischte Szenarien

Wenn die VM zwischen zwei 2008er-Hyper-V-Host verschoben wird, kann eine Migration über das Netzwerk nicht mit laufender VM durchgeführt werden. Sie können zwar den Befehl zur Migration geben, es wird aber die auf Abbildung 22.158 gezeigte Meldung erscheinen, die folgende Vorgehensweise ankündigt:

• Die VM wird angehalten, und ein gespeicherter Zustand wird erzeugt. Wohlgemerkt: Es wird nicht das Betriebssystem heruntergefahren, sondern lediglich pausiert.
• Alle erforderlichen Dateien werden verschoben.
• Auf dem neuen Host wird die Maschine wieder gestartet. Die Ausführung wird an derselben Stelle fortgesetzt, an der die VM zuvor angehalten wurde.

Im Klartext heißt dies: Das Betriebssystem wird zwar nicht heruntergefahren, und keine einzige Anwendung wird gestoppt, trotzdem gibt es eine unter Umständen längeren Dienstausfall – je nachdem, wie groß die VM ist. Beispielsweise dauert das Kopieren von 500 GByte VHD-Daten schon eine ganze Weile.

Abbildung 22.158 Ist ein 2008er-Hyper-V-Host beteiligt, führt eine Livemigration über das Netzwerk zu einem Dienstausfall.

Das Verschieben von virtuellen Maschinen von einem 2008er- zu einem 2012er-Hyper-V ist natürlich auch möglich – wenn auch nicht mehr »ganz so live«. Falls zwischen Hyper-V-Maschinen mit unterschiedlichem Versionsstand verschoben wird, klappt das Verschieben nur, wenn die virtuelle Maschine heruntergefahren, also das Betriebssystem beendet und nicht nur angehalten ist. Darauf weist VMM im Host auswählen-Dialog hin (Abbildung 22.159, zweite Meldung).

Abbildung 22.159 Wenn zwischen zwei Hyper-V-Versionen migriert wird, muss die VM komplett heruntergefahren werden (siehe zweite Meldung).

Und ohne VMM?

Migrationen von virtuellen Maschinen sind auch möglich, wenn kein VMM vorhanden ist, sondern die Admins mit dem Hyper-V-Manager arbeiten. Es ist dann nicht so schön und komfortabel, trotzdem aber durchführbar. Wenn Sie dieses Kapitel lesen und noch Hyper-V 2008 R2 nutzen: Bei der alten Version ging das mit Bordmitteln nicht, da war auf jeden Fall der VMM erforderlich.

Wenn Sie also keinen VMM haben, blättern Sie bitte zurück zu Abschnitt 22.7.2.

22.8.7 Konvertieren (P2V und V2V)

Neben der Verwaltung von Servern und virtuellen Maschinen bietet der Virtual Machine Manager einige recht interessante zusätzliche Funktionen. Diese betreffen unter anderem das Umwandeln von Fremd-VMs oder physikalischen Servern in Hyper-V-VMs.

Migration von »Fremd-VMs«

In vielen Unternehmen werden bereits Virtualisierungslösungen vorhanden sein – letztendlich ist es im Jahr 2013 fast undenkbar, dass ein Unternehmen bisher noch keine Erfahrungen gesammelt oder zumindest »Experimente« gemacht hat.

Die Verfügbarkeit von Hyper-V und Virtual Machine Manager bietet vielleicht für das eine oder andere Unternehmen oder eine Organisation die Möglichkeit, das Thema Servervirtualisierung etwas strukturierter, ganzheitlicher und nachhaltiger anzugehen.

Bei der Migration vorhandener virtueller Maschinen kommt es einerseits darauf an, die eigentlichen Festplattendateien »umzubauen«, andererseits ist es wichtig, diese so zu modifizieren, dass sie in der neuen »Hardwareumgebung« überhaupt starten. Sie wissen vielleicht aus Erfahrung, dass bereits das Tauschen von Festplatten zwischen zwei unterschiedlichen PCs schnell mit einem Bluescreen endet. Weiterhin muss die eigentliche Konfiguration von der ursprünglichen virtuellen Maschine übernommen werden, also beispielsweise die Größe des Speichers, die Anzahl der Netzwerkkarten und einiges andere mehr.

Die Konvertierung von bestehenden virtuellen Maschinen kann von folgenden Systemen aus erfolgen:

• VMware ESX/ESXi 3.5 Update 5
• VMware ESX/ESXi 4
• VMware ESX/ESXi 4.1
• VMware ESX/ESXi 5.1

Wichtig ist, dass ein Virtual Center Server vorhanden und in VMM integriert sein muss.

Wenn Sie von einer VMware Workstation zu Hyper-V konvertieren möchten, müssen Sie sich einer Drittherstellerlösung bedienen.

Virtualisierung von Hardware (P2V)

Nach wie vor ein beliebtes Thema ist die Konvertierung von physikalischen in virtuelle Maschinen. Auch hier bietet der VMM wertvolle Hilfe. Erfahrungsgemäß ist es gar nicht so einfach, P2V (Physical to Virtual) durchzuführen, VMM hat meiner Erfahrung nach eine ziemlich hohe Erfolgsquote. Die Probleme liegen, wenn es denn welche gibt, häufig in sehr hardwarenahen Treibern und Tools, die teilweise einfach nicht zu umschiffen sind. Hier hilft dann nur deinstallieren. Das VMM-P2V kann physikalische Server (mit Windows-Betriebssystem) im laufenden Betrieb konvertieren. Achten Sie bei datentragenden Servern dann aber auf Konsistenz. Sie können recht problemlos einen Testlauf machen, für die »echte« Konvertierung empfiehlt es sich, beispielsweise SQL Server-Dienste zu stoppen.

Ich zeige nun einen kompletten Konvertierungsvorgang, der mit dem auf Abbildung 22.160 gezeigten Menüpunkt beginnt.

Abbildung 22.160 Hier geht’s los.

Der Assistent beginnt mit der Abfrage des zu konvertierenden Servers. Die angegebenen Credentials müssen lokale Admin-Rechte auf dem Zielserver haben. Es wird unter anderem ein Agent installiert – und das geht nun mal nicht ohne Admin-Berechtigungen (Abbildung 22.161).

Abbildung 22.161 Auswahl des zu konvertierenden Servers. Credentials müssen lokale Admin-Rechte haben.

Der nächste Dialog des Assistenten erfragt den Namen der virtuellen Maschine (Abbildung 22.162). Dies ist natürlich der Name, unter dem die virtuelle Maschine unter Hyper-V geführt wird. Der Name des Betriebssystem ändert sich nicht, die Idee ist ja auch, dass die VM ein genaues Abbild des physikalischen Server ist – da wäre es fatal, wenn sich der Name ändern würde.

Abbildung 22.162 Das ist der Name, unter dem die neue VM geführt werden wird.

Abbildung 22.163 zeigt die erste Dialogseite, auf der wirklich etwas passiert. Sie müssen allerdings einmal auf System scannen klicken. Nach ungefähr einer Minute sollten unter Systeminformationen grundlegende Fakten über das zu konvertierende System angezeigt werden, wie beispielsweise das Betriebssystem, die Anzahl der Prozessoren oder die Festplatten und Netzwerkkarten.

Abbildung 22.163 »System scannen« untersucht die Konfiguration des zu konvertierenden Servers.

Abbildung 22.164 zeigt, auf Basis der zuvor ermittelten Informationen, einen Dialog zur Auswahl der zu übernehmenden Volumes. Das in diesem Beispiel konvertierte System ist ein DPM-Server, der ca. 100 Volumes hat. Ich übernehme allerdings hier nur die C-Platte.

Zu jeder zukünftig virtuellen Festplatte können VHD-Typ und -Größe angegeben werden – Sie können also noch etwas modifizieren.

Abbildung 22.164 Hier wählen Sie aus, welche Volumes konvertiert werden sollen. Wir nehmen hier nur die C-Platte mit.

In dem auf Abbildung 22.165 gezeigten Dialog können erste »Basiseinstellungen« vorgenommen werden, namentlich die Anzahl der Prozessoren und der Arbeitsspeicher. Weitere Details können eingestellt werden, wenn die VM angelegt ist.

In den nächsten Dialogseiten, die hier nicht im Detail besprochen sind, geht es um die Auswahl des Hosts (Abbildung 22.166), des Pfads und der Zuordnung der Netzwerkkarte(n). Im Dialog zur Auswahl des Hosts gibt es Empfehlungen, die aber nicht verbindlich sind. Es kann übrigens nicht schaden, einen Blick auf die Registerkarte Erklärung der Bewertung zu werfen.

Abbildung 22.165 Basiskonfiguration der VM

Abbildung 22.166 Im Auswahldialog für den Host gibt es Empfehlungen.

Den Verlauf der Konvertierung können Sie auf Abbildung 22.167 verfolgen. In Kurzform werden folgende Schritte durchgeführt:

• virtuelle Maschine anlegen
• Inhalte der Festplatten anlegen
• Maschine starten und VM-Komponenten installieren
• Agent von der Quellmaschine entfernen

Abbildung 22.167 Die Konvertierung läuft.

Der letzte Aspekt der Aufzählung der bei einem P2V-Vorgang vom VMM erledigten Punkte bezieht sich auf die Deinstallation eines Agent. Das Stichwort »Agent« beantwortet auch die Anfrage, wie VMM es schafft, eine Kopie des laufenden Servers zu erstellen. Eben! Es wird ein Agent auf dem zu konvertierenden Server installiert, der am Schluss des Prozesses wieder zurückgezogen (= deinstalliert) wird. Abbildung 22.168 zeigt einen Blick auf die installierten Programme auf dem zu konvertierenden Server, während der Vorgang läuft.

Abbildung 22.168 Hier die Antwort auf die Frage »Wie bewerkstelligt VMM die Konvertierung?«

---

Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.