ubuntuusers.de

Laufenden Rechner in virtuelle Maschine konvertieren

Archivierte Anleitung

Dieser Artikel wurde archiviert. Das bedeutet, dass er nicht mehr auf Richtigkeit überprüft oder anderweitig gepflegt wird. Der Inhalt wurde für keine aktuell unterstützte Ubuntu-Version getestet. Wenn du Gründe für eine Wiederherstellung siehst, melde dich bitte in der Diskussion zum Artikel. Bis dahin bleibt die Seite für weitere Änderungen gesperrt.

Achtung!

Die Verwendung dieses Howto geschieht auf eigene Gefahr. Bei Problemen mit der Anleitung melde dies bitte in der dazugehörigen Diskussion und wende dich zusätzlich an den Verfasser des Howtos.

Hinweis:

Diese Howto-Anleitung wurde zuletzt von SirVival am 09.07.2015 unter Ubuntu 14.04 und mit dem VmWare Player 6.0.6 erfolgreich getestet. Das Quell System war ein Lenovo X61s mit einer Samsung 470 64 Gigabyte SSD und das Ziel eine externe Festplatte von Toshiba (Stor.E Basics 1 Terrabyte).

Problembeschreibung

Die Folgenden Anleitung ist für Nutzer des VmWare Player gedacht. Oracles VirtualBox sollte ähnlich funktionieren, wurde aber noch nicht getestet.
Basiert auf http://trainofthought.segfault.gr/2010/06/14/mounting-a-raw-dd-image-as-a-vmware-virtual-disk/comment-page-1/ .

Zum Erstellen einer virtuellen Maschine gibt es für den Privatanwender diverse kostenlose Angebote. Das Aufsetzten einer virtuellen Maschine geht sehr leicht von Hand und erfordert keine großen Vorkenntnisse. Wie sieht es aber mit der Konvertierung eines laufenden Rechners aus? Eine typische Ausgangslage wäre, dass das System perfekt eingerichtet ist aber die Distribution / das Betriebssystem bekommt keine Sicherheitsupdates mehr und eine Neuinstallation einer aktuellen Distribution / eines aktuellen Betriebssystems wird nötig. Es soll z.B. sichergestellt werden, dass man bei der Neuinstallation keine Programmeinstellung oder Daten vergessen hat zu sichern. Die konvertierte Installation kann dann als eine Art Backup dienen, mit dem man, in dem Notfall, dass etwas nicht auf Anhieb funktioniert, weiter arbeiten kann. Oder die Neuinstallation ist auf dem neuesten Stand was Software und Pakete angeht. Man hat aber Dokumente in einer älteren Version der Software erstellt und will sichergehen, dass diese einwandfrei funktionieren. Bevor man jetzt unnötig Zeit darin investiert, wenn überhaupt möglich, die ältere Softwareversion in einer Neuinstallation einzurichten, nutzt man einfach eine Virtualisierung der alten Installation.

Wie geht man bei der Konvertierung eines laufenden Linux Systems vor?
Es gibt z.B. von VmWare den VCenter Converter. Oder wenn die virtuelle Maschine auf einem Apple OSx laufen soll von Parallels den Transporter Agent. Beide haben den Nachteil, dass sie unter Linux nur mit Einschränkungen funktionieren. Es geht dabei darum einen laufenden Linux Rechner live zu konvertieren (auf eine externe Quelle z.B.). VCenter Converter gibt es für Linux nur in einer recht alten Revision. Diese unterstützt als Ziel nur einen im Netzwerk evtl. vorhandenen VmWare ESX Server. Der VCenter Converter bietet ausserdem die Möglichkeit, via SSH, eine Konvertierung von einem weiteren Rechner im Netzwerk durchzuführen. Dafür muss auf dem Quell Linux Rechner nicht nur der Client, sondern auf der VCenter Converter Server installiert sein. Der zweite Rechner, von dem aus konvertiert werden soll, braucht nur den Client. Dies funktioniert sowohl mit einem Windows, OSx oder auch Linux Ziel. Leider benötigt auch dies einen zusätzlich im Netzwerk vorhandenen VmWare ESX Server. Für Privatanwender ist dies natürlich keine Lösung, erst einen Server mit einer kostenpflichtigen Enterprise Software aufzusetzen. Da Prallels Virtualisierungslösung für OSx gedacht ist, bietet sich diese Lösung nur an, wenn das Ziel sein sollte die virtuelle Maschine nicht unter Linux oder Windows auszuführen. Eine Konvertierung, der mit Parallels Transporter Agent erstellten virtuellen Maschine mit dem VCenter Converter scheitert leider, da VCenter Converter diese nicht als kompatible erkennt.

Wie geht man also vor, wenn es kein Konvertierungstool der Software Hersteller gibt? Die Lösung ist ziemlich einfach und wird im folgenden Schritt für Schritt erklärt.

Anleitung

Voraussetzung:

  • Der zu konvertierende Rechner ist gestartet

  • Das Vorhandensein eines Ziels (externe Festplatte, im Netzwerk etc.)

  • dd

  • VMware Player

  • Wie heißt meine Quelle (sda sdb etc.)?

  • Wie heißt mein Ziel (/media/usb/ etc.)?

  • Hardwaredaten der Quellen Festplatte (Zylinder etc.)

Als erstes öffnet man ein Terminal und führt folgenden Befehl aus:

cat /etc/fstab 

fstab liefert einem den Device Namen der angeschlossenen Speichermedien. Sollte das Ziel ein Netzwerklaufwerk sein, muss man es vorher natürlich unter media mounten.
Wichtig: Für später sollte man sich das Ergebnis von

sudo hdparm -I /dev/sda 

in eine Textdatei auf einem externen Ziel kopieren oder schreibt sie sich auf einen Notizblock (wobei sda hier die zu konvertierende Quelle ist).
Es werden für später die folgenden Infos benötigt:

  • Anzahl der Zylinder (cylinders)

  • Anzahl der Köpfe (heads)

  • Sektoren pro Spuren (sectors/track)

  • Gesamtzahl der Sektoren (LBA user addressable bei einer 32-bit und LBA48 bei einer 64-bit Quelle)

Hier am Beispiel der Samsung 470 SSD (der Aufbau der Ausgabe kann je nach hdpam Version variieren und hängt natürlich von der verbauten Festplatte ab):

sudo hdparm -I /dev/sda
/dev/sda:

ATA device, with non-removable media
	Model Number:       SAMSUNG 470 Series SSD                  
	Serial Number:      S0SUNEAB603049      
	Firmware Revision:  AXM09B1Q
	Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6
Standards:
	Used: ATA/ATAPI-7 T13 1532D revision 1 
	Supported: 8 7 6 5 & some of 8
Configuration:
	Logical		max	current
	cylinders	16383	16383
	heads		16	16
	sectors/track	63	63
	--
	CHS current addressable sectors:   16514064
	LBA    user addressable sectors:  125045424
	LBA48  user addressable sectors:  125045424
	Logical  Sector size:                   512 bytes
	Physical Sector size:                   512 bytes
	device size with M = 1024*1024:       61057 MBytes
	device size with M = 1000*1000:       64023 MBytes (64 GB)
	cache/buffer size  = unknown
	Nominal Media Rotation Rate: Solid State Device
Capabilities:
	LBA, IORDY(can be disabled)
	Queue depth: 32
	Standby timer values: spec'd by Standard, no device specific minimum
	R/W multiple sector transfer: Max = 16	Current = 16
	DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
	     Cycle time: min=120ns recommended=120ns
	PIO: pio0 pio1 pio2 pio3 pio4 
	     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
	Enabled	Supported:
	   *	SMART feature set
	    	Security Mode feature set
	   *	Power Management feature set
	   *	Write cache
	   *	Look-ahead
	   *	Host Protected Area feature set
	   *	WRITE_BUFFER command
	   *	READ_BUFFER command
	   *	DOWNLOAD_MICROCODE
	    	SET_MAX security extension
	   *	48-bit Address feature set
	   *	Device Configuration Overlay feature set
	   *	Mandatory FLUSH_CACHE
	   *	FLUSH_CACHE_EXT
	   *	SMART error logging
	   *	SMART self-test
	   *	General Purpose Logging feature set
	   *	WRITE_{DMA|MULTIPLE}_FUA_EXT
	    	Write-Read-Verify feature set
	   *	WRITE_UNCORRECTABLE_EXT command
	   *	{READ,WRITE}_DMA_EXT_GPL commands
	   *	Gen1 signaling speed (1.5Gb/s)
	   *	Gen2 signaling speed (3.0Gb/s)
	   *	Native Command Queueing (NCQ)
	   *	Host-initiated interface power management
	   *	Phy event counters
	   *	DMA Setup Auto-Activate optimization
	    	Device-initiated interface power management
	   *	Software settings preservation
	   *	SET MAX SETPASSWORD/UNLOCK DMA commands
	   *	WRITE BUFFER DMA command
	   *	READ BUFFER DMA command
	   *	Data Set Management TRIM supported (limit unknown)
Security: 
	Master password revision code = 65534
		supported
	not	enabled
	not	locked
		frozen
	not	expired: security count
		supported: enhanced erase
	6min for SECURITY ERASE UNIT. 6min for ENHANCED SECURITY ERASE UNIT. 
Checksum: correct 

Ist das Ziel z.B. eine externe Festplatte, dann führt man folgenden Befehl im Terminal aus (if ist die Quelle und of ist das Ziel):

sudo dd if=/dev/sda of=/media/usb/test.hdd bs=65535 

unter der Annahme sda ist die lokale Quelle und das externe Laufwerk ist unter /media/usb/ als Ziel eingebunden. Der Name test.hdd ist beliebig gewählt und kann abweichen. Die hdd Dateiendung ist nicht notwendig, wird hier aber verwendet, damit später eindeutig ist, dass es sich um die richtige Datei handelt. bs steht für Block Size und beschleunigt den Vorgang etwas, ist aber für das Funktionieren von dd nicht relevant. dd kopiert den Inhalt der Festplatte komplett Sektor für Sektor, d.h. auch leere Sektoren. Dies hat den Nachteil, dass die virtuelle Maschine auch genau soviel Platz verbraucht. Und nicht nur den belegten Speicher. Ideal ist dies nicht aber dafür kostenlos. Den Vorgang nicht abbrechen und das Terminal nicht schließen! Es gibt keine Fortschrittsanzeige daher etwas Geduld. Bei einer typischen USB 2.0 Festplatte ergibt sich ein Wert für die Kopiergeschwindigkeit um die 20 mb/s. Je nach Größe der Quelle variiert also die Zeitspanne bis zur Fertigstellung. Der Vorgang ist abgeschlossen, wenn das Terminal wieder Eingaben entgegen nimmt.

Als nächster erstellt man im VmWarePlayer eine virtuelle Maschine auf dem Zielrechner. Die Festplatte wählt man möglichst klein (0,900 GB) und wählt single file und nicht multiple files.
Sonst alles bei den Standardeinstellungen belassen, evtl. die Anzahl der CPU Kerne anpassen und die virtuelle Maschine erstellen. Die Größe des Arbeitsspeichers kann man auch im Nachhinein noch ändern. Die virtuelle Maschine nicht booten und den VmWarePlayer schließen.
Die nächsten Schritte sind etwas aufwendiger und man sollte sorgfältig vorgehen. Im Ordner der frisch erstellten virtuellen Maschine befindet sich eine Datei mit dem Namen *.vmdk. Diese Datei ist die virtuelle Festplatte der virtuellen Maschine und diese Datei wird nun so verändert, dass unsere test.hdd von der virtuellen Maschine übernommen wird. Dies ist notwendig, damit VmWare die kopierte Festplatte richtig ansprechen kann. Wie früher als man beim 386er im Bios die Festplatte manuell richtig eintragen musste und es nicht automatisch erkannt wurde. Weicht der LBA Eintrag z.B. ab gibts beim Start der virtuellen Maschine dann einen mount Fehler. Die Anzahl der Zylinder muss stimmen etc. .
Für den Fall, dass bei den folgenden Schritten etwas schief geht, erstellt man vor dem Verändern der *.vmdk einfach ein Sicherung mit dem Namen *.vmdk_old. Entweder im Dateimanager oder wenn man schon ein Terminal auf hat mit dem Pfad zur virtuellen Maschine und führt folgenden Befehl aus:

cp *.vmdk *.vmdk_old 

Hat man den hdparm Schritt weiter oben vergessen ist dies kein Beinbruch, sondern es gibt es die Möglichkeit mit fdisk an die benötigten Werte zu kommen.

fdisk -l test.hdd

Disk test.hdd: 64.0 GB, 64023257088 bytes
255 Köpfe, 63 Sektoren/Spur, 7783 Zylinder, zusammen 125045424 Sektoren
Einheiten = Sektoren von 1 × 512 = 512 Bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Festplattenidentifikation: 0x12291228

   Gerät  boot.     Anfang        Ende     Blöcke   Id  System
test.hdd1   *        2048    41017343    20507648   83  Linux
test.hdd2        41030010   120889124    39929557+  83  Linux
test.hdd3       120889344   125044735     2077696   82  Linux Swap / Solaris 

Ist dies getan, öffnet man die vmdk Datei der virtuellen Maschine mit einem Texteditor der Wahl (VIM etc.) und entfernt alles vor # Disk DescriptorFile und speichert. Evtl. auftauchende Fehlermeldung beim Speichern ignorieren. Nun modifiziert man nach und nach die Einträge. Aus monolithicSparse wird z.B. monolithicFlat.

Original Datei:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicSparse"

# Extent description
RW 1886208 SPARSE "Ubuntu.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "921"
ddb.geometry.heads = "64"
ddb.geometry.sectors = "32"
ddb.longContentID = "59b0002c7b45995e2562fcf7fffffffe"
ddb.uuid = "60 00 C2 9f 86 2c 99 b2-fa 9a c3 05 d2 6a 42 93"
ddb.virtualHWVersion = "10" 

Zu modifizieren:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=19c54193
parentCID=ffffffff
isNativeSnapshot="no"
# monolithicSparse durch monolithicFlat ersetzen
createType="monolithicSparse"

# Extent description
# LBA user addressable durch den LBA Wert ersetzen
# SPARSE durch FLAT ersetzen
# Name dd file durch den vorher gewählten Dateinamen der Festplattenkopie ersetzen und eine 0 hinzufügen
RW LBA user addressable SPARSE "Name dd file"

# The Disk Data Base 
#DDB

ddb.adapterType = "lsilogic"
#cylinders durch die tatsächliche Anzahl der Zylinder ersetzen
ddb.geometry.cylinders = "cylinders"
#heads durch die tatsächliche Anzahl der Schreib-/Leseköpfe ersetzen
ddb.geometry.heads = "heads"
#sectors/track durch die tatsächliche Anzahl Sektoren pro Spuren ersetzen
ddb.geometry.sectors = "sectors/track"
ddb.longContentID = "b5f2a4797f73010538e85c6c19c54193"
ddb.toolsVersion = "9413"
ddb.uuid = "60 00 C2 9f 56 4f 7e 97-a2 e0 01 a9 50 18 eb 36"
ddb.virtualHWVersion = "10" 

Für die 64 Gigabyte Samsung 470 SSD sieht das ganze dann so aus:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=19c54193
parentCID=ffffffff
isNativeSnapshot="no"
createType="monolithicFlat"

# Extent description
RW 125045424 FLAT "test.hdd" 0

# The Disk Data Base 
#DDB

ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.longContentID = "b5f2a4797f73010538e85c6c19c54193"
ddb.toolsVersion = "9413"
ddb.uuid = "60 00 C2 9f 56 4f 7e 97-a2 e0 01 a9 50 18 eb 36"
ddb.virtualHWVersion = "10" 

Speichern und Editor schließen.

Anschließend kann man die virtuelle Maschine im VmWare Player starten und das System bootet von der mit dd erstellten Kopie der Festplatte.

Diese Revision wurde am 14. Februar 2020 08:11 von Heinrich_Schwietering erstellt.
Die folgenden Schlagworte wurden dem Artikel zugewiesen: Howto