vir207: Txomin Barturen
Advanced Storage Infrastructure Best Practices to Enable Ultimate Hyper-V Scalability

vir305: Karthik Lakshminarayanan
Microsoft RemoteFX: Rich Windows Desktop Experience for VDI and Session Virtualization

vir304: Benjamin Armstrong
Hyper-V and Dynamic Memory in Depth

vir307: Rand Morimoto
Getting the Most out of Windows Server 2008 R2 Hyper-V with the Integration of the System Center Suite

vir309: Iftekhar Hussain
Microsoft System Center Virtual Machine Manager 2008 R2: Advanced Virtualization Management

vir310: Taylor Brown, Vijay Tewari Networking and Windows Server 2008 R2 Hyper-V: Deployment Considerations

vir312: Arno Mihm,James Schwartz
Realizing a Dynamic Datacenter Environment with Windows Server 2008 R2 Hyper-V and Partner Solutions

vir313:Barry Flanagan,Robin Brandl
VDI from Microsoft and Citrix: What is it? How do I manage it? What benefits does it provide?

vir314 – Allen Stewart
Virtualization Scenarios for Business Critical Application

vir315: Clint Huffman,Kenon Owens
Windows Server 2008 R2 Hyper-V Performance Analysis: How You Can Get the Most out of Hyper-V

vir316: Bernhard Tritsch
Remote Desktop Session Host vs. Virtual Desktop Infrastructure Smackdown

vir319: Kenon Owens
Dynamic Infrastructure Toolkit for Microsoft System Center Deployment: Architecture and Scenario Walkthrough

vir322: Soumya Das Bhaumik
Hyper-V Backup Deep Dive: A Look Under the Hood

vir324: Michael Greene,Nick Smith
Hyper-V for the VMware Administrator

vir403: Janssen Jones
Virtualization FAQ, Tips, and Tricks

wsv205: Max Herrmann, Michael Kleef
Remote Desktop Services: Virtual and Session-Based Desktops and Applications Architecture with Partners

wsv307: Justin Graham
Windows Server 2008 R2 SP1

wsv315: Steven Ekren, Symon Perriman
Guest vs. Host Clustering: What, When, and Why

Der physische Computer, auf dem der virtuelle Computer ausgeführt wird, wurde nicht gefunden. Führen Sie den Befehl ‘ipconfig /flushdns’ aus um den DNS-Cache zu leeren. Versuchen Sie anschließend erneut eine Verbindung herzustellen. Sollte das Problem weiterhin bestehen, wenden Sie sich an den Administrator des physischen Computers oder an den zuständigen Netzwerkadministrator.

Nach länger Recherche fand ich dann eine Lösung an die ich niemals gedacht hätte: im Blogpost “Hyper-V Virtual Machine Connection and Direct Access” wurde ich fündig. Hier wird beschrieben, das es durch DirectAccess, überigens eine super interessante Technologie die wir auch benutzen (siehe Artikel Howto-Einrichtung von DirectAccess), zu einem Fehlverhalten in der Namensauflösung kommt. Der Autor beschreibt eine “Quick and Dirty” Lösung die folgendermaßen aussieht:

Sie öffnen Regedit und löschen  aus der Registry den Schlüssel

“HKLM\SOFTWARE\Policies\Microsoft\Windows NT\DNSClient
\DnsPolicyConfig”

mit allen Unterschlüsseln heraus. Danach teilen wir dem Dnscache Dienst mit dem Befehl

sc control dnscache paramchange

mit das sich seine Parameter geändert haben und er seine Konfiguration neu einlesen soll.

Das Vorgehen hat bei mir das Problem gelöst. In dem Artikel gibt es noch einen Kommentar, der auf ein nicht ganz so radikales Vorgehen hinweist. Vieleicht auch eine Lösung.

Zur Konfiguration dient ein Windows 7 64-bit mit Remoteverwaltung Tools, wie diese installiert werden hat Jan Kappen in diesem Blogartikel bereits erklärt, weshalb ich an dieser Stelle nicht weiter darauf ein gehe. Bevor die Server per Windows 7 konfiguriert werden können, müssen einige Anpassungen vorgenommen werden.

Nachdem Windows 7 zur Remoteverwaltung angepasst wurde, müssen die Hyper-V Server angeglichen werden.
Unter dem Punkt „Remoteverwaltung konfigurieren“ muss der Zugriff per MMC aktiviert werden.

Desweiteren muss die Firewall angepasst werden, dieses ist über die Kommandozentrale Möglich: 

netsh advfirewall firewall set rule group="Windows-Verwaltungsinstrumentation (WMI)" new enable=yes

Wer das Konfigurieren per Konsole nicht mag kann auf den Core Configurator 2.0 zurückgreifen, welcher von Carsten Rachfahl in einem Blogartikel hier bereits vorgestellt wurde.

Nach einem Neustart des Betriebssystems kann die Netzwerkkonfiguration vorgenommen werden.

Die Hyper-V Server sind mit jeweils drei Netzwerkkarten ausgestattet:

• Das Heartbeat-Netz, welches die Verbindung der Hyper-V Server untereinander bereitstellt
• Das Client-Netz, welches das Netz in unserer Domäne ist
• Das iSCSI-Netz, welches die Anbindung zum iSCSI Target bereitstellt, welches auf dem Windows Storage Server läuft.

Beispiel für eine Netzwerkkonfiguration:

Anschließend wird auf beiden Server das Failovercluster Feature (Option 11) aktiviert, welches mit dem Failoverclustermanager in späteren Schritten konfiguriert wird.

Ausblick Teil 4: Installation und Konfiguration des iSCSI Target

Die Erweiterung der VHD teilt sich in zwei logische Schritte:

• Schritt 1: Erweitern des VHD Containers
• Schritt 2: Erweitern des Volumes

zu Schritt 1: Voraussetzung für das Erweitern ist ein System das nicht aus der VHD bootet. Ich starte dazu ein parallel auf meinem Notebook installiertes Windows 7. In diesem installiere ich das Programm “VHDReziser” (Download http://vmtoolkit.com/files/default.aspx). Nachdem Sie das Tool auf Ihrem System installiert haben, rufen Sie es auf und geben den Pfad der zu vergrößernden VHD (hier “D:\VHDs\W2K8R2.vhd”) und einen Ziel VHD (hier “D:\VHDs\W2K8R2-2.vhd”) an. Jetzt erzeugt das Tool eine neue zweite VHD und kopiert blockweise die Daten der ersten VHD in diese hinein. Das hat den großen Vorteil, dass die ursprüngliche VHD unangetastet bleibt.

zu Schritt 2: Das Volume erweitern wir mit dem Windows Komandozeilentool “diskpart”. Dazu starten wir uns eine Eingabeaufforderung mit administrativen Rechten (Rechtsklick auf Eingabeaufforderung) und geben darin:

diskpart

ein. Als nächstes wählen wir die VHD aus

select vdisk file=D:\VHDs\W2K8R2-2.vhd
attach vdisk

auf die wir unsere Operationen ausführen wollen. Jetzt müssen wir das Volume angeben welches wir erweitern möchten. Wenn Sie es nicht wissen lassen Sie sich mit

list volume

alle vorhandenen Volumes anzeigen. In unserem Fall ist dies das 5 Volume welches wir mit

select volume 5

anwählen. Jetzt könne wir das Volume erweitern. Das geschieht mit dem Befehl

extend

Zum Abschluss müssen wir nur noch die VHD wieder vom System abhängen. Dazu verwenden wir die Befehle

select vdisk file=D:\VHDs\W2K8R2-2.vhd
detach vdisk

und verlassen dann das “diskpart” Tool mit dem Befehl “exit”. In meinem Fall muss ich noch die beiden VHDs umbenennen da ich ja jetzt aus der vergrößerten VHD booten möchte und diese muss dann D:\VHDs\W2K8R2.vhd” heißen.

Deswegen habe ich die aktuelle Debian Distribution lenny geladen und es einfach mit dem Kernel 2.6.33.5 ausprobiert. Im Folgenden finden Sie die Schritte zum Nachvollziehen:

1. Erstellen Sie eine VM mit 512MB und mind. 5GB Platte
2. Laden Sie ein Debian lenny 64bit ISO Image (z.B. das “debian-505-amd64-netinst.iso”) herunter, dieses dann als DVD in der VM mounten und damit eine Debian Grundinstallation durchführen
3. Installieren Sie einige Kernel Entwicklungspakete mit dem Befehl “apt-get install build-essential ncurses-dev kernel-package fakeroot”
4. Zusätzlich benötigen wir eine neuere Version des Packets “kernel-package”. Diese erhalten wir indem wir in der Datei “/etc/apt/sources.list” die Zeile “deb http://ftp.de.debian.org/debian squeeze main” ergänzen, mit dem Befehl “apt-get update” die neuen Packetinformationen heruntergeladen und dann schließlich mit “apt-get install kernel-package” dieses Paket updaten.
5. Danach wechsel wir mit dem Befehl “cd /usr/src” in das Kernelquellverzeichnis und laden dort mit dem Befehl “wget http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.33.5.tar.bz2” die gewünschten Kernelquelle herunter
6. Diese dekomprimieren wir dann mit “tar xf linux-2.6.33.5.tar.bz2” an Ort und Stelle
7. Wir wechseln mit “cd linux-2.6.33.5” in das Kernell Quellverzeichnis. Jetzt stehen Sie vor der Wahl  welchen Kernel Sie erzeugen wollen. Sie können einfach die Standartwerte übernehmen Befehl “make menuconfig”, Sie können die Konfiguration des alten Kernel als Vorlage benutzen indem Sie die aktuelle Konfiguration nach .config kopieren Befehl "cp /boot/config-2.6.32-2-amd64 .config" oder Sie laden sich eine für Debian vorkonfigurierte Version unter “config-2.6.33-2-amd64.gz” herunter, entpacken und benutzen diese um den Kernel zu bauen (mit Befehl "cp config-2.6.33-2-amd64 .config")
8. Jetzt schalten wir das Erzeugen der Hyper-V Komponenten als ladbare Kernelmodule ein, in dem wir den Befehl “make menuconfig” ausführen, nach “Device Drivers –> Staging Drivers –> Microsoft Hyper-V Client Drivers” navigieren und diese als ladbare Module aktivieren
9. Mit dem Befehl “make-kpkg clean” und einem darauf folgenden “fakeroot make-kpkg –-initrd –-revision=hv.custom.1.0 kernel_image” erzeugen wir dann das Kernelpacket (Dauer ca. 1 Stunde)
10. Nach dem Kopilieren wechseln wir mit “cd ../” in das Verzeichnis “/usr/src” und installieren mit “dpkg -i linux-image-2.6.33.5_hv.custom.1.0_amd64.deb” den neuen Kernel
11. Damit die Hyper-V Module in der Kernel Ramdisk vorhaden sind, tragen wir in die Datei “/etc/initramfs-tools/modules”  jeweils einen Zeile mit “hv_vmbus”, “hv_storvsc”, “hv_blkvsc” und “hv_netvsc” ein
12. Normalerweise würde das System eine initrd erzeugen, da das aber komischerweise nicht der Fall ist erzeugen wir diese manuell mit dem Befehl  “mkinitramfs -o /boot/initrd.img-2.6.33.5”. Danach updaten wir mit dem Befehl “update-initramfs –t –u –k 2.6.33.5” die Bootramdisk, so dass Sie auch unsere Hyper-V Integrations Komponenten kennt. Zuletzt müssen wir noch die Bootkonfiguration mit dem Befehl “update-grub” aktualisieren
13. Jetzt können wir mit dem Befehl “reboot” die VM neu starten und booten den neuen Kernel
14. Im letzten Schritt melden Sie sich an und prüfen mit dem Befehl “lsmod” ob die Hyper-V Module geladen werden. Sie sollten in der Ausgabe vier Module sehen: hv_vmbus, hv_storvsc, hv_blkvsc und hv_netvsc.

Anzumerken ist bei dieser Lösung, dass momentan noch die Zeitintegration, die Herunterfahrmöglichkeit und der Heardbeat fehlen. Dieses sind Features die mit den Hyper-V Integration Komponenten 2.1 voraussichtlich mit Kernel 2.6.35 kommen werden.

Vorlage für diese Konfiguration ist der folgender Artikel von Matthew Mattoon:
http://blog.allanglesit.com/Blog/tabid/66/EntryId/44/Hyper-V-Guests-Compile-Linux-2-6-32-on-Debian.aspx

Im zweiten Teil der Reihe möchte ich erklären wie eine der Hyper-V Server installiert wird und welche ersten Anpassungen zur Konfiguration von Nöten sind.

Als Grundlage dient der kostenlose Hyper-V Server 2008 R2 von Microsoft welcher bei Microsoft heruntergeladen werden kann.

Eine Installationsanleitung hat Jan Kappen http://www.hyper-v-server.de/news/installation-eines-hyper-v-server/ in einem Blogartikel bereits verfasst.

Nach erfolgreichen Abschluss der Installation bekommt man folgende Maske zusehen:

Hier werden nun die ersten Anpassungen vorgenommen. Beginn bei Domäne und Computername.
Da beide Server in unsere bestehende Rachfahl.de Domäne kommen nenne ich die beiden Server Hyper-V1 und Hyper-V2.
Anschließend habe ich das Betriebssystem ge-updatet und das System Neugestartet.

Nachdem der Neustart durchgeführt wurde, wurden die Failoverclusterfeature aktiviert und unter Remoteverwaltung der Zugriff über die Remoteverwaltungstools Aktiviert werden.

Als letzter Punkt muss die Firewall noch angepasst werden das wird über die Konsole gemacht mit folgenden Befehl:

Bei dem zweiten Hyper-V Server mache ich die selben Schritte mit dem unterschied das ich dort den Namen in der Domäne auf Hyper-V2 setze.

Ausblick Teil 3: Konfiguration der Hyper-V Server mit Windows 7

Im Rahmen meiner Projektarbeit zur Abschlussprüfung zum Fachinformatiker für Systemintegration war es meine Aufgabe eine kostengünstige Hochverfügbarkeitslösung zu finden. Die Wahl viel wie nicht anders zu vermuten als Microsoft Gold Partner auf Hyper-V. Aus Kostengründen haben wir uns für den Hyper-V Server und den Windows Storage Server entschieden.

In dieser Reihe möchte ich die Live Migration mit Hyper-V vorstellen und demonstrieren wie ein Failovercluster installiert wird. Die Live-Migration beinhaltet das transparente verschieben einer virtuellen Maschine von einem physikalischen Host auf einen anderen. Der Vorteil an der Live-Migration ist, wenn ein Administrator eine Wartung oder ein Problem an einem physikalischen Host feststellt, kann die darauf laufende Instanz einfach auf ein anderes System migriert werden ohne das angebundene Clients die Verbindung zu der Maschine verlieren oder die virtuelle Maschine etwas davon bemerkt. Dadurch werden Ausfälle von Instanzen gering gehalten und Arbeitsausfälle vermieden.

Ich werde von der Installation der Server bis hin zur Live-Migration meine Schritte erklären.
In den ersten Teil möchte ich zeigen wie wir das Projekt Realisiert haben (siehe Grafik).

Auf die Einzelheiten der verwenden Hard und Software und der Grund warum wir sie so gewählt haben komme ich im Verlauf dieser Reihe noch zu sprechen wenn die einzelnen Punkte konfiguriert werden.

Ausblick:

Im zweiten Teil der Reihe gehe ich auf die Installation und Konfiguration der Hyper-V Server ein.

Da Daten und deren Sicherungen für Unternehmen einen existenziellen Wert darstellen, möchten wir hier ausdrücklich darauf hinweisen, dass wir für die hier bereitgestellten Skripte und Methoden  keinerlei Haftung übernehmen und Sie diese auf eigene Gefahr einsetzen.

Wie sieht nun unsere Methode aus? Hyper-V bringt seit der ersten Version die Möglichkeit mit sich eine VM zu exportieren. Bei diesem Vorgang werden die kompletten Daten, d. h. die Platten (VHDs), die Snapshots (falls vorhanden) und die Konfiguration, in einem Format in ein Verzeichnis kopiert,  so dass diese jederzeit auf einen anderen Host kopiert und wieder importiert werden können. Daraus kann sich ein Problem ergeben: Da die Daten kopiert werden, und das nur auf einer Platte des Hosts passieren kann (keinem Netzlaufwerk), benötigt die Maschine mindestens den gleichen freien Plattenplatz, wie die gesamte VM belegt.

Weiterhin kann die VM beim Exportvorgang nicht laufen, das heißt sie ist entweder heruntergefahren (was wir präferieren) oder sie ist zumindest gespeichert. Diese Ausfallzeit der VM kann, je nach Größe der VHDs und Snapshots, schon einige Minuten dauern. Als Beispiel dauert der Export unseres Exchange Server mit ca. 80 GB um die 30 Minuten. Natürlich möchten wir den Exportvorgang nicht von Hand anstoßen, sondern automatisieren. Deswegen haben wir uns ein PowerShell Script geschrieben, das mittels Aufgabenplaner in regelmäßigen Interwallen diesen Exportvorgang durchführt. Wenn Sie möchten kopiert dann dieses Script, nach Abschluss des Exportvorgangs, die Daten auf einen beliebigen Netzwerkpfad, damit die Daten nicht nur auf dem Host liegen.

Hier der grobe Ablauf des Scripts:

1. Maschine herunterfahren oder schlafen legen
2. Exportvorgang auf lokalen Datenträger
3. Maschine starten oder aufwecken
4. Gegebenenfalls den Export auf Netzwerkfreigabe kopieren

Damit unser PowerShell Script funktioniert, benötigen wir die PSHyperv Library die James O’Neill entwickelt und unter  CodePlex (Download unter http://www.codeplex.com/psHyperV) frei zur Verfügung stellt.  Achtung: die aktuelle Version funktioniert nur mit der PowerShell V2, allerdings auf beiden Hyper-V Varianten. Zum reibungslosen Installieren der Library sind folgende Schritte vorab durchzuführen:

1. Sie laden das ZIP-Archive in ein Verzeichnis (z.B. C:\Temp) herunter
2. Sie wenden das Sysinternal Tool “streams” an, um die Kenzeichnung, dass die Datei aus dem Internet geladen wurde (“Zone.Identifier”), zu entfernen
3. Sie entpacken das Archive in einem temporären Verzeichnis (z.B. c:\Temp)

Danach führen Sie die Installation des Library durch: Rechtsklick auf das “install.cmd” Script und auswählen “Als Administrator ausführen”. Jetzt werden Sie gefragt, ob Sie “.Net Framework 2” und “PowerShell” installiert haben. Ist das nicht der Fall, dann brechen Sie bitte die Installation ab und holen dieses nach. Erfüllen Sie alle Voraussetzungen, dann drücken Sie “Enter” und das Script kopiert die Library und nimmt alle erforderlichen Einstellungen vor. In dem Screenshot sehen Sie zwei Fehler, die auf einer nicht Core Installation auftreten. Diese Fehler können Sie ignorieren und bestätigen einige weitere Male die Installationsschritte.

Nach erfolgreicher Installation sollte ein Powershell-Fenster aufgehen, indem Sie die Installation mit dem PowerShell Befehl:

get-command –module HyperV

überprüfen können.

Nach der erfolgreichen Installation der PsHyperV Bibliothek laden Sie unser PowerShell Script “HyperV-Backup.ps1” herunter (die aktuelle Version finden Sie hier). Das ZIP Archive entpacken Sie in einem Verzeichnis z.B. “C:\Tools”. Auch hier sollten Sie das Sysinternal Tool “streams” anwenden, damit Powershell das Script ausführen kann.

Einen ersten Überblick über die Scriptoptionen erhalten Sie, wenn sie das Script nun aus einer Powershell (Achtung Administratoren Rechten erforderlich) mit dem Argument “-?” oder “-help” aufrufen z.B.: “C:\Tools\HyperV-Backup.ps1 –?”. Als Hilfestellung für den Einsatz gebe ich im folgenden einige Beispiele, wie Sie dieses Script benutzen können:

1. lokaler Export eines VMs:

C:\Tools\HyperV-Backup.ps1 –VM W2K8-VM –ExportPath D:\Exports

Schritte die das Script ausführt:

1. die VM "W2K8-VM” wird heruntergefahren
2. Sie wird in das Verzeichnis C:\Exports\W2K8-VM exportiert und ein dort gegebenenfalls vorhandener alter Export gelöscht
3. die VM wird wieder gestartet

2. lokaler Export einer VM mit Kopie auf Sicherungsserver:

C:\Tools\HyperV-Backup.ps1 –VM W2K8-VM –ExportPath
D:\Exports  -RemotePath \\Storage\Sicherung$ –verbose

Schritte die das Script ausführt:

1. die VM "W2K8-VM” wird heruntergefahren
2. Sie wird in das Verzeichnis C:\Exports\W2K8-VM exportiert und ein dort gegebenenfalls vorhandener alter Export gelöscht
3. die VM “W2K8-VM” wird wieder gestartet
4. Der Export wird in die Netzwerkfreigabe “\\Storage\Hyper-V-Sicherungen$\W2K8-VM” kopiert und ein dort gegebenenfalls vorhandener alter Export gelöscht
5. Die Export unter “D:\Exports\W2K8-VM” wird gelöscht

Zusätzlich gibt das Script, wegen des Schalters –verbose einige Informationen auf der Konsole aus.

3. remote Export mit Kopie auf Sicherungsserver:

C:\Tools\HyperV-Backup.ps1 –VM Debian1-VM –Server Hyperv5
–ExportPath D:\Exports  -SaveState -RemotePath
\\Storage\Sicherung$ –verbose

Schritte die das Script ausführt:

1. die VM "Debian1-VM” wird gespeichert (Option –SaveState)
2. Sie wird in das Verzeichnis D:\Exports\Debian1-VM exportiert und ein dort gegebenenfalls vorhandener alter Export gelöscht
3. die VM “Debian1-VM” wird wieder aufgeweckt
4. Der Export wird in die Netzwerkfreigabe “\\Storage\Hyper-V-Sicherungen$\Debian1-VM” kopiert und ein dort gegebenenfalls vorhandener alter Export gelöscht
5. Die Export unter “D:\Exports\W2K8-VM” wird gelöscht

Zusätzlich gibt das Script wegen des Schalters –verbose einige Informationen auf der Konsole aus.

Nun sollte es ein leichtes sein, mit Hilfe der Windows Aufgabenplanung lokale und auch remote HyperV VMs zu exportieren.

Wenn Sie Anregungen, Kritik oder Verbesserungsvorschläge zu diesem Script haben, dann mailen Sie uns diese doch unter:

Falls diese Script sehr nützlich für Sie ist, dann würden wir uns über eine positive Beurteilung unser Hyper-V PinPoint Lösung sehr freuen.

Download-Link:

Version 0.91: HyperV-Backup-V0.91.zip
Update 14. Juli 2010: Fix beim Export eines Remote Systems. Es wurde beim Export einer Remote VM nicht der entfernte Export Pfad geprüft sondern fälschlicherweise der Lokale Pfad.

Version 0.9: HyperV-Backup-V0.9.zip
Erste Version