Hyper-V running Linux-VMs - Best Practices

Microsoft hat einige Hinweise zusammengestellt, wie sich virtuelle Maschinen mit Linux unter Hyper-V optimal einrichten und betreiben lassen.

Best Practices for running Linux on Hyper-V

Linux and FreeBSD Virtual Machines on Hyper-V

V2V oVirt <--> HyperV

Um eine VM von oVirt 3.0 nach HyperV zu migrieren, muss man folgendermaßen vorgehen:

Virtuelle Maschine in oVirt herunterfahren und exportieren.
Die exportierte Festplatte (RAW-Image ohne Dateiendung) auf das Hyper-V Storage kopieren.
Mittels vhdtool.exe in das Hyper-V Format (VHD) konvertieren --> vhdtool.exe /convert "folder/virtualdisk"

Das vhdtool hängt an das RAW-Image einen VHD footer an, wie im obigen Screenshot ersichtlich ist.
Nach dem Konvertieren hängt man .vhd an den Dateinamen an (z.B.: ren C:\temp\temp temp.vhd)
Nun kann man in Hyper-V eine VM erstellen und booten.

Unter umständen erhält man bei Linux VMs die folgende Fehlermeldung:
 "e2fsck: The superblock could not be read or does not describe a correct ext2 filesystem"
Dies kann man folgendermaßen beheben:

In meinem Fall lag es daran, dass der Linux Kernel die Partitionslabel geändert hat.

Mit fdisk -l die Partitionslabel abfragen und per "vi /etc/fstab" an die ausgabe con fdisk -l anpassen.
Zum Beispiel von /dev/vdb1 nach /dev/sdb1.
Sollte vi im read only mode gestartet werden, muss man das filesystem im r/w Modus remounten: mount -o remount,rw /

Hyper-V 3.0 - Kernel Panic durch Hyper-V Treiber

Aktualisiert man eine Hyper-V VM von CentOS 5.5 (oder RHEL 5.5) nach 5.9 oder 5.10, resultiert der nächste Bootvorgang in einer Kernel Panic.

Das gleiche Ergebnis erhält man auch bei der Migration (P2V oder V2V) nach Hyper-V.

Da die Kernel in CentOS bzw. RHEL 5.9 und höher die Version 3.1 der Hyper-V Integration Services Module enthalten, erwartet das System, dass diese beim Booten geladen werden. Da diese Module im 5.5er Kernel nicht enthalten waren, werden sie beim Kernel Upgrade Prozess von mkinitrd nicht erkannt und deshalb im neuen ramdisk Image nicht hinzugefügt.

Um dieses Problem zu beheben, muss man folgendermaßen vorgehen:

1. Von CentOS (RHEL) Installationsmedium booten
2. "linux rescue" beim "boot:" prompt eingeben
3. Alle Dateisysteme im read-write Modus mounten:

   mount --bind /proc /mnt/sysimage/proc
   mount --bind /dev /mnt/sysimage/dev
   mount --bind /sys /mnt/sysimage/sys
   chroot /mnt/sysimage

   cd /boot 

4. Backup von der Ramdisk erstellen:
   
   mv initrd-2.6.18-194.32.1.el5.img initrd-2.6.18-194.32.1.el5.old
5. Neue Ramdisk mit mkinitrd erstellen:
   
   mkinitrd initrd-2.6.18-194.32.1.el5.img 2.6.18-194.32.1.el5
6. Server rebooten

HyperV 3.0 - Panic: early exception

Resultiert das Starten einer Linux VM in einer Kernel Panic (early exception 06 rip 10) , kann man dies beheben, indem man für die entsprechende VM NUMA* deaktiviert.

Dieser Fehler tritt bei manchen VM Konfigurationen beim Zuweisen einer bestimmten Speicherkapazität auf oder jedoch beim Zuweisen von CPUs (in unserem Falle 8).

Um NUMA zu deaktivieren geht man folgendermaßen vor.

1. VM ausschalten
2. Anzahl der CPUs / Speicher reduzieren bis die Maschine hochfährt
3. vi /boot/grub/grub.conf
4. An die Kernelzeile "numa=off" anhängen
5. VM herunterfahren
6. Anzahl der CPUs / Speicher auf gewünschten Wert erhöhen

* Non-Uniform Memory Access - Hardware-Konzept für Multi-Prozessor-Systeme, welches jeder CPU einen eigenen Bereich des Arbeitsspeichers zuordnet

VHD verkleinern und in fixed umwandeln

Nachdem ich schon den Dualboot von einer bestehenden VHD erläutert habe, möchte ich nun darauf eingehen, wie man eine bestehende dynamische VHD verkleinern und in den Typ "fixed" umwandeln kann.


Das Problem besteht darin, dass Windows versucht, die VHD auf den angegebenen Speicherplatz (bspw. 40GB) zu erweitern, was unter Umständen mangels Speicherplatz in einem Bluescreen resultieren kann.
Nun kann man die dynamische VHD verkleinern und direkt "fixen", d.h. die VHD belegt sofort den Speicherplatz, den man für die virtuelle Festplatte gewählt hat.

Start --> Ausführen --> cmd


diskpart 

select vdisk file=<Pfad zur VHD Datei>
attach vdisk
select volume <Volume Nr>
shrink [desired=<Größe in MB>]

select vdisk file=<Pfad zur VHD Datei>
detach vdisk
exit

Danach mit VHD resizer in "fixed" umwandeln, fertig!

VHD- und AVHD-Dateien zusammenführen

Hier eine kurze Anleitung, wie man VHD- und AVHD-Dateien nach dem Löschen von Snapshots wieder zusammenführen kann.

Ausgeblendete Netzwerkkarte im Geräte-Manager anzeigen

Zieht man beispielsweise unter Hyper-V eine virtuelle Maschine um, so erkennt das System eine neue Netzwerkkarte, welche dann denn Namen "Lan-Verbindung 2" erhält.

Versucht man nun diese Schnittstelle nach Lan-Verbindung umzubenennen, erhält man die Fehlermeldung: "Lan-Verbindung bereits vorhanden, anderen Namen wählen.".


Um die Netzwerkschnittstelle jedoch wieder auf den ursprünglichen Wert umzubenennen, muss man folgende Schritte durchführen:

1. Erweiterte Systemeigenschaften --> Umgebungsvariablen --> Systemvariablen --> Neu
2. Name der Variablen: devmgr_show_nonpresent_devices
3. Wert der Variablen: 1

Nun können die Geräte wieder angezeigt werden.

Geräte Manager starten --> Ausgeblendete Geräte anzeigen


Hier kann man nun die alte Netzwerkkarte löschen.
Um die Karte umbenennen zu können, fehlt abschließend noch ein Schritt.


Start --> Ausführen --> regedit


Zum Schlüssel "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Network" navigieren und die veralteten Einträge entfernen (Sicherung der Registry erstellen).


Nach einem Neustart sollte die Netzwerkkarte automatisch "Lan-Verbindung" heißen.

Windows von bestehender VHD booten

Möchte man eine vorhandene virtuelle Windows-Installation auf einem physikalischen Rechner booten, so kann man das VHD-Image auf der lokalen Maschine einbinden und davon booten.

Zuerst die VHD-Datei auf die lokale Festplatte kopieren, z.B.: C:\VHD\W2k8.vhd

Vom Windows-Installationsdatenträger booten
Achtung: Es muss die Windows 7 oder Server 2008 R2 DVD sein, vorherige Versionen können nicht mit VHDs umgehen.
Im Installationsmenü mit Shift+F10 die Konsole öffnen.

VHD einbinden:

diskpart
select vdisk file=C:\VHD\W2k8.vhd (LW-Buchstabe kann vom tatsächlichen Pfad abweichen)
attach vdisk
exit

Bootmanager und MBR auf Festplatte schreiben und nach Windows 7/2008-Installationen suchen lassen:

bootrec /fixmbr
bootrec/fixboot
bootrec/rebuildBcd

Beim nächsten Startvorgang erscheint ein Bootmenü, in welchem man nun das System auswählen kann.

Linux Integration Services 3.1 released

Microsoft hat die Linux Integration Services 3.1 bereits am 27.07.2011 released.
Der Microsoft TechNet RSS-Feed hat mich allerdings erst heute erreicht.
Features:

• Driver support: Linux Integration Services supports the network controller and the IDE and SCSI storage controllers that were developed specifically for Hyper-V.
• Fastpath Boot Support for Hyper-V: Boot devices now take advantage of the block
  Virtualization Service Client (VSC) to provide enhanced performance.
• Timesync: The clock inside the virtual machine will remain synchronized with the clock on
  the virtualization server with the help of the pluggable time source device.
• Integrated Shutdown: Virtual machines running Linux can be shut down from either Hyper-V Manager or System Center Virtual Machine Manager by using the “Shut Down” command.
• Symmetric Multi-Processing (SMP) Support: Supported Linux distributions can use up to 4 virtual processors (VP) per virtual machine.
  SMP support is not available for 32-bit Linux guest operating systems running on
  Windows Server 2008 Hyper-V or Microsoft Hyper-V Server 2008.
  
• Heartbeat: Allows the virtualization server to detect whether the virtual machine is running and responsive.
• KVP (Key Value Pair) Exchange: Information about the running Linux virtual machine can
  be obtained by using the Key Value Pair exchange functionality on the Windows Server 2008 virtualization server.
  

Unterstützte Betriebssysteme:

• Red Hat Enterprise Linux 6.0 and 6.1 x86 and x64 (Up to 4 vCPU)
• CentOS 6.0 x86 and x64 (Up to 4 vCPU)

Hier geht es zum Download.
Für die Betriebssysteme SUSE Linux Enterprise Server 10 und Red Hat Enterprise Linux 5, muss man nach wie vor auf die Version 2.1 zurückgreifen, welche es hier gibt.

debian 6.0.1a unter Hyper-V

Linux-Distributionen unter Hyper-V Testtag 2:
Nachdem die CentOS Installation erfolgreich virtualisiert ist, habe ich heute die Virtualisierung von debian Lenny getestet.
Da hier ein Kernel (2.6.38) zum Einsatz kommt, welcher Hyper-V unterstützt, werden keine Integration-Services benötigt.

Installationsmodus: Server ohne GUI

Nach der Grundinstallation sind noch einige Pakete zu installieren:

apt-get update
aptitude update
apt-get install -y build-essential
apt-get install -y ncurses-dev kernel-package fakeroot
apt-get install -y linux-headers-`uname -r`
apt-get install -y linux-source-`uname -r | awk -F"-" '{print $1}'`
cd /usr/src
wget -c http://www.kernel.org/pub/linux/kernel/v2.6/linux-2.6.38.tar.bz2
bzip2 -d linux-2.6.38.tar.bz2
tar xf linux-2.6.38.tar
cd linux-2.6.38
cp /boot/config* ./.config
make menuconfig

Nun werden die “Hyper-V Client Drivers“ aktiviert.
Device Drivers --> Staging Drivers

Kernel-Konfiguration verlassen und Konfiguration speichern.
Nun geht es weiter mit der Kompilierung und der Installation des Kernels:

make-kpkg clean
fakeroot make-kpkg --initrd --append-to-version=-hyperv kernel_image kernel_headers
cd ..
dpkg -i linux-image-2.6.38-hyperv_2.6.38-hyperv-10.00.Custom_amd64.deb linux-headers-2.6.38-hyperv_2.6.38-hyperv-10.00.Custom_amd64.deb
echo -e "hv_vmbus\nhv_storvsc\nhv_blkvsc\nhv_netvsc" >> /etc/initramfs-tools/modules
update-initramfs –u –k 2.6.38-hyperv

Austausch der Netzwerkkarte

Tauscht man die “ältere Netzwerkkarte” gegen die Hyper-V Karte, hat eth0 keine IP-Adresse. Grund hierfür ist der Eintrag in der Datei “70-persistent-net.rules”.

nano /etc/udev/rules.d/70-persistent-net.rules

Alle Einträge unterhalb der Kommentare löschen.
Nach einem Reboot übernimmt die Hyper-V Karte die Einstellungen der alten Netzwerkkarte.

Nachdem ich nun debian und CentOS unter HyperV laufen habe, denke ich, dass ich mich für debian entscheiden werde. Das System bootet schon mal wesentlich schneller als CentOS (40sec. gegenüber 150sec.) und im Gesamten scheint es performanter zu laufen.

CentOS 5.6 unter Hyper-V

Hier mal ein kleines How-To, wie man CentOS 5.6 unter Hyper-V zum Laufen kriegt.
Für mich hat sich diese Aufgabe gestellt, da ich nun auch meinen Nagios-Server in die Tonne treten und durch eine virtuelle Maschine ersetzen will.
Welche Distribution schlussendlich das Rennen macht, entscheide ich, wenn Nagios + Centreon installiert sind.
Ich schwanke zwischen Debian Lenny und CentOS 5.6.

Zu allererst sind aber die Distributionen unter Hyper-V zum Laufen zu bringen, was nicht unbedingt trivial ist.
Die synthetische Netzwerkkarte, SCSI-Laufwerke, Herunterfahren per Hyper-V-Manager etc. werden nicht standardmäßig unterstützt.
Jedoch bietet Microsoft die Hyper-V Integration Services 2.1 an, mit welchen man diese Features integrieren kann.

Die Installation von CentOS 5.6 startet man im Textmodus und wählt den Modus Server (Desktop abwählen).
Ist die Grundinstallation auf die ich nicht näher eingehe abgeschlossen, wird das System rebootet und es werden die Systemupdates heruntergeladen:

yum update
reboot

Nach einem erneuten Reboot, werden die für die Installation der Linux Integration Services benötigten Tools installiert:

yum groupinstall "Development Tools"
yum install kernel-devel
yum install gcc

Nun werden die Linux Integration Services 2.1 heruntergeladen, entpackt und installiert.

cd /lib/modules/2.6.18-xx
rm source build
ln -s ../../../usr/src/kernels/2.6.18-xx build
ln -s build source
mkdir -p /mnt/cdrom
mount /dev/cdrom /mnt/cdrom
mkdir /opt/linux_ic
cp –R /mnt/cdrom/ /opt/linux_ic
umount /mnt/cdrom
cd /opt/linux_ic/
make
make install

Mit folgenden Befehl kann man prüfen, ob die Hyper-V-Subkomponenten laufen:

/sbin/lsmod | grep vsc

Folgende Ausgabe sollte nun zu sehen sein:

blkvsc
storvsc
netvsc
vmbus
scsi_mod

Nun hat man eine Linux-VM mit installierten Integrationskomponenten.

Microsoft System Center - Data Protection Manager 2010

Serverkonsolidierung mittels Hyper-V: abgehaktMigration der Domäne auf 2008 R2: erledigt
Umstellung von Exchange 2003 auf 2010: abgeschlossen
Monitoring mittels Nagios: CHECK!
Sodele, wer jetzt denkt, bei mir käme Langeweile auf, hat sich geirrt. ;-)
Mir hat sich vor der Umstellung der Domäne die Frage gestellt, wie ich sämtliche Server und eventuell einige Clients möglichst komfortabel sichere. Da wir MAPS-Abonnenten sind, wurde ich im Action Pack schnell fündig --> Microsoft DPM 2010!
Wichtige Argumente für den Einsatz von DPM waren für mich:
- Support für Hyper-V 2.0
- Funktionen zur Sicherung von Windows Client-Computern (von Windows XP bis zu Windows 7)
- kein teurer Kauf von Zusatzmodulen notwendig (Exchange-Agents, SQL-Agents...)
- komfortable und relativ einfache Verwaltung (Fehlersuche dank Microsoft manchmal etwas umständlich, aber machbar)

Ein weiterer Vorteil von DPM stellt sich für mich dadurch dar, dass ich vom Hostsystem aus die VM sichern kann, ohne diese herunterfahren zu müssen, um sie wegzukopieren.
Mittels DPM kann ich alles per VSS sichern (alle 15 Minuten, 7 Tage die Woche, 30 Tage).
Bei Fileservern, an welchen ständig der Datenbestand verändert wird, eine feine Sache. :-)

Darüberhinaus kann ich im DPM noch Bare-Metal-Recovery aktivieren, d.h., entschließe ich mich dazu, aus einer VM doch eine physikalische Maschine zu erstellen, realisiere ich das Ganze über BMR.

Wieso schreib ich den ganzen Mist hier?

Sollte jemand auf der Suche nach einer Sicherungssoftware sein, mit welcher man ohne großen Aufwand Clients, Server, Hyper-V-Maschinen, SQL- bzw. Exchange-Datenbanken im Griff hat, sollte sich auf jeden Fall Microsofts DPM2010 anschauen.

Nun läuft alles und es wird noch ein bissel rumgetestet, dann kommt schon wieder das nächste Projekt: Panda Gatedefender Integra weg - Watchguard XTM 22 rein

VMDK in VHD umwandeln

Hier eine Anleitung wie man mittels dem Tool VMDK2VHD aus einer VMWare-Maschine eine Hyper-V-Maschine erstellt.
1.) VMWare-Tools deinstallieren
2.) VM herunterfahren
Falls die VM auf einem SCSI-Laufwerk installiert ist und das Betriebssystem Windows XP, 2003 oder älter ist, muss man den IDE-Treiber zur VM hinzufügen.
Dieser Schritt ist bei Windows Vista, Windows 7 oder Server 2008 nicht notwendig.
3.) IDE-Laufwerk zur VM hinzufügen (Größe beliebig).
“Adapter: IDE 0 Device: 0” unter “Virtual Device Node”
4.) VM hochfahren und in der Laufwerksverwaltung prüfen, ob ein neues Laufwerk erkannt wurde.
5.) Virtuelle Maschine herunterfahren und IDE-Laufwerk entfernen (delete from disk). VM nicht mehr hochfahren!
6.) VMDK-Datei ins VHD-Format konvertieren. Vmdk2Vhd utility.
7.) VMware Server deinstallieren und die Rolle Hyper-V hinzufügen.
8.) Neue Maschine in Hyper-V mit bestehender Festplatte erstellen.
9.) Hochfahren, Integrationsdienste installieren und neustarten.
10.) IP-Konfiguration prüfen und analog der Einstellungen unter VMWare konfigurieren.
11.) Geräte-Manager auf korrekt installierte Treiber überprüfen.
12.) Nochmals neustarten.
13.) Dienste und Anwendungen auf korrekte Funktion prüfen.
14.) Fertig!