Die Hitze der vergangenen Tage ist nicht nur für Mensch und Tier eine Belastung. Auch so mancher älterer, verstaubte Computer hält der extremen Wärme nicht stand. So stürzte ein Computer bei einem Kunden regelmäßig ab, es ging sogar so weit, dass der Rechner selbst im BIOS ausging. Das Problem war nach einer Diagnose ausgemacht. Der Speicher ist in Ordnung, aber die CPU will nicht mehr richtig. Die dicke Staubschicht, die große Hitze und die Dauerbelastung durch die Spezialsoftware hat somit ihren Tribut gefordert. Da kein Ersatzrechner auf die Schnelle greifbar war wurde die Idee das System virtualisiert auf einem der Server aufzusetzen wohlwollend aufgenommen.

Es zeigten sich aber zwei Probleme, die es zu lösen galt:

1. Für ein komplettes Festplatten Image ist kein Platz mehr auf dem Server
2. Der Dongle für die Spezialsoftware muss an die virtuelle Maschine durchgereicht werden.

Festplattendump anlegen

Die 400GB Festplatte aus dem defekten Rechner enthielt nur ca. 25GB an Daten (inkl. Windows), also musste es doch eine Möglichkeit geben nur diese 25GB zu kopieren und keine 375GB zu verschwenden. Das Zauberwort heißt hier: „Sparse-Files„. Diese Art von Dateien können mehrere Terabyte groß sein und sogar größer als die Partition auf der sie sich befinden. Diese Dateien belegen aber nur soviel Platz bzw. Datenblöcke im Dateisystem, wie Daten vorhanden sind. Lücken zwischen den einzelnen Blöcken werden nicht gezählt.  Wichtig ist, dass das eingesetzte Dateisystem diese Art von Dateien unterstützt. Im konkreten Fall waren noch 100GB auf einem ext4-Dateisystem verfügbar.
Für die gesamte Prozedur benötigt man kurzfristig das Doppelte der zu sichernden Daten, in diesem Fall 50GB.

Der Dump der großen 400GB NTFS-Partition wurde mit dem Tool ntfsclone erzeugt, welches Sparse-Files anlegt:

$ ntfsclone -o sde1.img /dev/sde1

Obiger Befehl speichert die erste Partition der 5. Festplatte (sde) in der Datei sde1.img.

Der Dump wird relativ zügig erstellt, da es ja „nur“ 25GB an Daten sind. Die Dateigröße wird bei einem „ls“ mit 400GB angezeigt, die wirklich effektive Größe der Datei erfährt man durch nutzen des Parameters: „-ls“

$ ls -ls -h

Die Kopie ist aber nur die halbe Miete. Möchte man wie geplant das Windows virtualisiert ausführen benötigt man eine „komplette“ Festplatte, also einen Master-Boot-Record.

Die Partitionstabelle sichert man mit sfdisk:

$ sfdisk -d /dev/sde > sde.fstab

Schaut man sich die Datei an, so sieht man dass die erste Partition beim Sektor 63 beginnt. Die Daten bis zu diesem Sektor enthalten den MBR, welchen man mit dd sichert:

$ cat sde.fstab
# partition table of /dev/sde
unit: sectors

/dev/sde1 : start= 63, size=781401537, Id= 7, bootable
/dev/sde2 : start= 0, size= 0, Id= 0
/dev/sde3 : start= 0, size= 0, Id= 0
/dev/sde4 : start= 0, size= 0, Id= 0

$ dd if=/dev/sde of=sde.mbr bs=512 count=63

Nachdem man nun alle nötigen Bestandteile zusammengetragen hat kann man beginnen ein entsprechendes Festplattenabbild zusammenzubauen

Festplattenabbild zusammenbauen

Hierfür legt man zuvor eine neue Datei an (hdd.img), welche das Festplattenabbild enthalten soll. Die Datei soll erst mal so groß sein, wie die eigentliche Festplatte:

$ truncate -s $(( (63+781401537)*512 )) hdd.img

Im nächsten Schritt schreibt man den MBR und was sonst noch so bis zur ersten Partition an Daten vorhanden waren:

$ dd if=sde.mbr of=hdd.img bs=512 count=63

Nun gilt es die virtuelle Festplatte mit Daten zu füllen, da das dd-Tool keine Sparse Dateien schreiben kann (so weit ich weiß), nutzt man das Tool ddrescue:

$ ddrescue -S -o $((63*512)) sde1.img hdd.img

Obiger Befehl kopiert alle Daten aus der Datei sde1.img in die Datei hdd.img und beginnt damit an der errechneten Position.

Nach dieser Prozedur hat man ein Festplattenabbild welches nur ca. 25 GB auf dem Datenträger belegt aber immer noch „wachsen“ kann. Die eigentliche Partition hält aber maximal 100GB, so ist es ratsam dieses Festplattenabbild noch zu verkleinern. Hier bietet sich das Programm gparted an. Ich werde jetzt nicht auf die Nutzung von gparted eingehen, da es von der Benutzeroberfläche selbsterklärend ist 😉

Hat man die Partition z.B. auf 35GB verkleinert kann man die Abbilddatei entsprechend zusammenschrumpfen, die 71681986 ist in diesem Fall die Größe der Partition in Sektoren. Nicht vergessen darf man beim Zurechtstutzen die ersten 63 Sektoren mit dem MBR:

$ truncate -s $(( (63+71681986)*512 )) hdd.img

Danach hat man ein verkleinertes Festplattenabbild, welches man nun z.B. in libvirt bzw. qemu nutzen kann, um das neue alte System wieder zum Leben zu erwecken.

Dongle durchreichen

Das durchreichen des Dongles an das virtuelle Windows war nach dem vorhergehenden Prozedere der leichtere Teil. Man fügt in die Maschinenbeschreibung einfach einen entsprechenden Abschnitt ein (es kommt libvirt zum Einsatz, da auch noch andere virtuelle Maschinen auf dem Server laufen). Auf der virsh-Konsole öffnet man die Beschreibungsdatei und fügt einen entsprechenden Block ein. Die dafür nötigen Daten hat man zuvor mit lsusb ermittelt:

<hostdev mode='subsystem' type='usb' managed='yes'>
  <source>
    <vendor id='0x0529'/>
    <product id='0x0001'/>
    <address bus='3' device='4'/>
  </source>
</hostdev>

Anschließend kann man die virtuelle Maschine starten und der Dongle ist entsprechend verfügbar.

Fazit

Diese Aktion bei unserem Kunden war wesentlich schneller als ein neues Windows aufzusetzen und darin die Spezialsoftware zu installieren. Zumal die ganzen Einstellungen in der Software immer noch zu machen gewesen wären. So war diese Wiederbelebung des Systems in meinen Augen der effizienteste Weg. Durch den nun wesentlich leistungsfähigeren Prozessor gehen die Berechnungen schneller, wodurch die Auslastung steigt. Auch geht keine Zeit mehr beim Wandern im Betrieb verloren, da der Zugriff via VNC von jedem autorisierten Rechner aus erfolgen kann ohne das man seinen Platz verlassen muss. Und auch aus Hardwaresicht (RAID5 & Backup) sollte dieser wichtige Teil der Produktionskette nicht mehr so leicht ausfallen.

Bild: (C) Christian Jansky (CC-BY-SA-3.0)