Windows 8(.1) Autostart

Hinzufügen von Programmen zum Autostart unter Windows 8 bzw. 8.1:

• mit Windows Taste + "R" "Ausführen" starten
• "shell:startup" (ohne Anführungszeichen) eingeben und mit "ENTER" bestätigen
• es öffnet sich ein Ordner, in dem Programmverknüpfungen abgelegt werden können

Nach einem Neustart werden die hier abgelegten Programme / Dateien automatisch gestartet.

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