QCOW2 Images lokal einbinden

Mit Hilfe des „Network Block Device“ nbd lassen sich qcow2-Images auch lokal einbinden. Dazu muss zunächst das passende Kernelmodul geladen werden:

modprobe nbd max_part=8

wobei max_part die maximale Zahl der Partitionen pro Device festlegt
Das Image erstellet:

qemu-img -f qcow2 disk.qcow2 20G

Dann läßt sich das Image dem Device zuordnen:

qemu-nbd -c /dev/nbd0 disk.qcow2

und regulär via parted oder fdisk formatieren, mit einem Dateisystem versehen und mounten:

fdisk /dev/nbd0
..
mkfs.ext4 -L disk /dev/nbd0p1
mount /dev/nbd0p1 /mnt/disk

Nach dem umount löst:
qemu-nbd -d das Image vom Network Block Device

UUID für RHEV oder ovirt erstellen

Ein Hypervisor Node für ovirt oder RHEV bekommt eine eindeutige UUID. Diese errechnet sich via dmidecode aus der BIOS-Seriennummer. Simple Whitebox-Server haben aber oft keine individuelle Serien-Nummer im Bios. Setzt man eine ovirt/RHEV-Umgebung mit solchen Serversystemen auf, bekommen alle Hypervisor-Nodes die gleiche UUID und das RHEV/ovirt-Setup schlägt fehl.
Um das zu vermeiden kann der Verwalter, vor der Installation des Hypervisors und dessen ovirt/RHEV-Steuerdaemons vdsm, eine zufällige UUID für das jeweilige System erzeugen:
mkdir /etc/vdsm; cp /proc/sys/kernel/random/uuid /etc/vdsm/vdsm.id
Die vdsm-Installation wird diese ID nicht überschreiben, so dass im Anschluss alle Hypervisor Node sindividuelle UUIDs vorweisen.

rhev/ovirt Defekte Disk-Images aus der DB entfernen

Wenn es beim Import von Templates oder VMs aus der Export-Domain zu Problemen kommt, kann es sein, dass Disk-Images im Status „locked“ bleiben. Das blockiert die importierte VM oder das Template, so dass diese sich nicht löschen lassen. In der Folge läßt sich die Export-Domain im Zweifelsfall nicht mehr abhängen.
Um den Fehler zu beheben, muss der Administrator die Disk-Images auf der Export-Domain manuell löschen und zudem die Einträge aus der Datenbank auf dem rhev-m/ovirt-Server händisch entfernen:

[root@rhev ~]$ su - postgress
-bash-4.1$ psql -U engine
Password for user engine:
psql (8.4.13)
Type "help" for help.
select * from vms_for_disk_view;

Listet die Disk-IDs aller vorhandenen VMs und Templates auf. Die Ansicht läßt sich für die betroffene VM/Template filtern:

engine=> select * from vms_for_disk_view where array_vm_names='{evm-v5104-r}';
array_vm_names | device_id | entity_type
----------------+--------------------------------------+-------------
{evm-v5104-r} | a4063ac5-7591-483d-a29f-c8f7a464b583 | TEMPLATE
{evm-v5104-r} | 5507e4b2-53f2-466f-8c02-7fa55eb870c0 | TEMPLATE
{evm-v5104-r} | da126728-9071-4ea8-8f49-8dfd55c9173a | TEMPLATE
{evm-v5104-r} | 246bdbe7-d3b7-4b40-917c-55d62f8d53b3 | TEMPLATE
{evm-v5104-r} | 687613cb-09e0-4876-93a8-d4f697789bbf | TEMPLATE
(5 rows)

Dann lassen sich die Disk-Zuweisungen nach einander aus der Datenbank entfernen

engine=> delete from images where image_group_id='246bdbe7-d3b7-4b40-917c-55d62f8d53b3';
DELETE 1
...

Sobald die defekten Images aus der Datenbank gelöscht wurden, läßt sich das Template, bzw. die VM entfernen.

Gluster-FS Quickstart

Das Test-Setup eines Gluster-FS-Clusters läßt sich relativ zugig durchziehen, allerdings gibt es dabei ein paar Hindernisse zu beachten.
Basis für das Test-Setup: Linux-System mit 8 GB RAM, KVM, libvirt und auf Wunsch Virt-Manager. Darauf laufen später zwei bis vier virtuelle Gluster-Nodes.

Node-Setup:

Als Basis-OS für die Nodes kommt CentOS 6.3-x64 zum Einsatz. Jeder Node verfügt über 1 CPU, 1 GB RAM und ca 32 GB Disk.
Setup des CentOS als „Minimal“. Nach dem Setup, die IP-Adresse des LAN-Adapters in
/etc/sysconfig/network-scripts/ifcfg-eth0
ja nach LAN-Konfiguration anpassen und den Adapter so konfigurieren, dass er beim Systemstart automatisch startet:
ONBOOT="yes"

SE-Linux und Firewall abschalten, da diese Komponenten den Verbindungsaufbau der Gluster-Nodes verhindern können:
In der Datei
/etc/selinux/config
die Konfiguration auf
SELINUX=disabled
ändern.
Die vorgegebenen Firewall-Regeln löschen und die Firewall auf „Durchzug“ schalten:
iptables -F
Distribution aktualisieren:
yum update
anschliessen den Node neu starten.

Nach dem Neustart das Repository der „Extra Packages for Enterprise Linux“ einfügen:
rpm -i http://download.fedoraproject.org/pub/epel/6/i386/epel-release-6-7.noarch.rpm
Aktuell ist das die Version Version 6.7. Das kann sich aber ändern. Daher vor der Installation einfach im Browser:
http://download.fedoraproject.org/pub/epel/6/i386
eingeben und in der Paketliste nach „epel-release“ suchen. Dann die aktuelle Versionsnummer dieses Pakets verwenden.

Anschliessend die Gluster-Komponenten und die NFS-Tools installieren.
yum install glusterfs-server nfs-utils
Das Gluster-FS verfügt über einen NFS-Server, der jedoch aktuell nur NFSv3 beherrscht. Das bitte beim Mounten von NFS-Freigaben berücksichtigen

Nach erfolgter Installation den RPC-Daemon und den Gluster-Service starten:
service rpcbind start
service glusterd start

Über
chkconfig --list
prüfen, ob beide Dienste bei einem Reboot automatisch starten. Falls die Dienste nicht gelistet sind, sie mit chkconfig --add hinzufügen und mit chkconfig dienst on auf Autostart setzen.

Gluster-Konfiguration

Diese Setup-Prozedur für alle Gluster-Nodes wiederholen. Der eben erstellte Node (VM) läßt sich auch Klonen, aber Achtung: Je nach Klon-Verfahren arbeiten Abbilder der VM mit der identischen System-UUID des Originals, was zu einem Scheitern der Gluster-Verbindung führt. Jeder Node muss hier mit einer eigenen eindeutigen System-UUID identifiziert werden.

Nachdem alle Nodes laufen und sich pingen können, läßt sich auf dem „Node1“ die Verbindung zu den benachbarten Bricks aufbauen:
gluster peer probe node2
gluster peer probe node3
....

Und ein Volume erstellen (distributed, replicated, striped, distributed replicated …… etc)
gluster volume create vol1 node1:/vol1 node2:/vol2
gluster volume start vol1

Auf das Volume können Clients entweder via NFS oder den Gluster-Client zugreifen. Linux-System brauchen für den Gluster-Client die Pakete glusterfs-fuse, glusterfs, fuse (Fedora/Redhat/Centros) bzw. glusterfs-client, fuse (Debian/Ubuntu).
Bei einem NFS-Mount nicht die Option -o nfsvers=3 vergessen.

Vsphere VMs nach KVM konvertieren

Der Umzug einer Linux-, Windows-2008R2- oder -7-VM von Vsphere 5 nach KVM funktioniert prinzipiell ganz simpel:

Einfach einen Klon der VM auf einen NFS-Datenträger erstellen oder die VM via Storage Vmotion dort hin verschieben. Die Ziel-VM sollte dabei eine Fat-provisioned VMDK verwenden.
Die NFS-Freigabe auf dem KVM-Host mounten und das „Flat“-VMDK-File in ein QCOW-Image konvertieren:

kvm-img -O qcow2 /nfsfreigabe/vmdk-flat.vmdk /var/lib/libvirt/images/ziel.qcow2

Anschließend auf dem KVM-Host eine VM erstellen und die Disk als IDE-Laufwerk zuweisen (bei Linux-VMs: VirtIO). Windows 7/2008 passt die Treiber automatisch an die Umgebung an. In der neu gestarteten KVM-VM müssen dann nur noch die VMWare-Tools entfernt und die VirtIO-Treiber für KVM (Download über Redhat oder Fedora-Website) installiert werden

Windows XP mit Treiber-Inject

Windows XP passt sich leider nicht automatisch an die neue Umgebung an. Eine wie oben beschrieben übertragene XP-VM endet unter KVM mit einem Blue-Screen. Vor der Konvertierung muss der Anwender erst einen Registry-Patch einspielen, der die Standard-IDE-Treiber aktiviert. Dazu auf http://support.microsoft.com nach dem Schlüsselwort „mergeide.reg“ suchen. Dort findet sich ein KB-Eintrag mit dem ausführlichen Registry-Patch. Damit dieser Funktioniert müssen zudem die IDE-Treiber atapi.sys, intelide.sys, pciide.sys und pciidex.sys in %systemroot%/system32/drivers vorhanden sein.
Falls einer der Treiber fehlt lässt er sich aus %systemroot%/Driver Cache/i386/driver.cab extrahieren.