Forum: PC Hard- und Software VBox: bestehende Systemplatte in VM starten


von Uhu U. (uhu)


Lesenswert?

VBox kann die Daten einer VM auch auf einer Partition oder einer ganzen 
Platte halten.

Ist es möglich, ein bestehendes System - z.B. Ubuntu - über diesem 
Mechanismus parallel zum Hostsystem laufen zu lassen? (Natürlich ohne 
die Integrität der Platte dabei zu gefährden.)

Kann man eine komplette Platte, die per VBox mit Linux konfiguriert 
wurde, später direkt per Hardware starten, statt über VBox?

Letzteres wäre eine bequeme Methode, ein neues System zu konfigurieren 
und nach und nach Dinge vom laufenden System hinüber zu kopieren, ohne 
dauernd die Systeme abwechselnd booten zu müssen, oder zwei Rechner 
parallel laufen zu haben.

von ./. (Gast)


Lesenswert?

Ich habe vor gefuehlten droelfzig Jahren ein selbstgebautes Linux
per VMWare2.0 direkt von einer Partition unter einem Windows XP 
gebootet.

Das Linux war aber fuer einen Read-Only-Modus praepariert und
haette so auch von CD booten koennen. Da waren auch alle
notwendigen Treiber mit im Kernel.

Wenn Grub in die Linuxpartition installiert wird, kann man immer
noch mit einem anderen Bootlader die Partition beim Booten auswaehlen.
Ein Parallelbetrieb sollte so moeglich sein.

Was Aerger machen wird, ist die Hardwareerkennung die in die Linuxe
eingebaut ist.

Wirst Du wohl ausprobieren muessen...

Viel Erfolg!

von Uhu U. (uhu)


Lesenswert?

./. schrieb:
> Was Aerger machen wird, ist die Hardwareerkennung die in die Linuxe
> eingebaut ist.

Ja, bei Windows ist das zu erwarten. Bei Linux eher nicht, bzw. das 
Problem ist behebbar.

: Bearbeitet durch User
von Uhu U. (uhu)


Lesenswert?

Ich habs mittlerweile mit einer nagelneuen Platte ausprobiert: man kann 
unter VB darauf installieren und die Platte anschließend als Hostsystem 
booten. Das ist eine sehr bequeme Möglichkeit, eine Arbeitsumgebung zu 
portieren.

Allerdings halte ich es für ratsam, anders als in der Dokumentation 
beschrieben nicht /dev/sd? als Device zu nehmen, sondern den zugehörigen 
Link aus /dev/disk/by-id/ - damit geht man Problemen mit wechselnden 
Laufwerksbezeichnungen aus dem Weg.

von Uhu U. (uhu)


Angehängte Dateien:

Lesenswert?

Einen bösen Schönheitsfehler hat die unter VB partitionierte Platte: die 
große Partition ist um 1024 Byte misaligned.

Jetzt stellt sich natürlich die Frage, was ich mit dem weitgehend 
konfigurierten System anstelle: neu partitionieren und die ganze Übung 
nochmal, oder versuchen, den Defekt irgendwie zu reparieren.

Platz genug, ein Backup irgendwo anders unterzubringen habe ich.

Wie geht man da am geschicktesten vor?

: Bearbeitet durch User
von Konrad S. (maybee)


Lesenswert?

Evtl. kannst du die Partition mit (g)parted verschieben. Innerhalb einer 
VM mit zusätzlich eingebundener "Festplatte" über eine SystemRescue-CD 
booten.

von Uhu U. (uhu)


Lesenswert?

Es handelt sich nicht um eine "Festplatte", sondern um eine Festplatte, 
eine echte.

von Konrad S. (maybee)


Lesenswert?

Muss die Festplatte nicht in eine vdk oder etwas in der Art gekapselt 
werden, um sie in der VM zu benutzen? Das gekapselte Ding meine ich mit 
"Festplatte".

von Uhu U. (uhu)


Lesenswert?

Die bestehende Partition einfach um 1024 Byte zu verschieben, geht 
jedenfalls nicht, denn sie belegt den gesamten Restplatz. Also doch neu 
aufsetzen.

Das Problem ist, dass parted durch den Mechanismus mit der "Festplatte" 
nicht mitbekommt, dass die Platte 4k-Sektoren hat. Sie sie wird dann vom 
Installer wie eine mit 512-Byte-Sektoren partitioniert.

Ich werde wohl nicht darum herum kommen, die System erst mal auf der 
blanken Hardware zu installieren und es erst dann in der VB laufen zu 
lassen.

von Konrad S. (maybee)


Lesenswert?

Uhu Uhuhu schrieb:
> Das Problem ist, dass parted durch den Mechanismus mit der "Festplatte"
> nicht mitbekommt, dass die Platte 4k-Sektoren hat. Sie sie wird dann vom
> Installer wie eine mit 512-Byte-Sektoren partitioniert.

Genau dieses Problem hatten wir in der Arbeit, allerdings mit VMware. 
Bisher keine Lösung. :-(

von Uhu U. (uhu)


Lesenswert?

Die Platte auf echter Hardware installieren und dann erst an die VM 
koppeln, würde ich mal sagen. Ich probiers morgen aus.

von Rolf Magnus (Gast)


Lesenswert?

Uhu Uhuhu schrieb:
> Ich habs mittlerweile mit einer nagelneuen Platte ausprobiert: man kann
> unter VB darauf installieren und die Platte anschließend als Hostsystem
> booten. Das ist eine sehr bequeme Möglichkeit, eine Arbeitsumgebung zu
> portieren.
>
> Allerdings halte ich es für ratsam, anders als in der Dokumentation
> beschrieben nicht /dev/sd? als Device zu nehmen, sondern den zugehörigen
> Link aus /dev/disk/by-id/ - damit geht man Problemen mit wechselnden
> Laufwerksbezeichnungen aus dem Weg.

Dafür hat man Probleme mit wechselnden Disk-IDs. Das sind nämlich 
Hardware-IDs, die für jede Platte anders sind. Besser ist es, das Label 
oder die UUID zu nehmen, entweder über /dev/disk/by-label bzw. 
/dev/disk/by-uuid oder gleich in der fstab statt das device sowas wie 
"LABEL=<label>" oder "UUID=<uuid>" angeben. Siehe "man fstab".

von Theodor (Gast)


Lesenswert?

./. schrieb:
> Was Aerger machen wird, ist die Hardwareerkennung die in die Linuxe
> eingebaut ist.

Typischerweise ist Windows da eher problematischer, wo hattest/erwartest 
du Probleme?

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Uhu Uhuhu schrieb:
> Das Problem ist, dass parted durch den Mechanismus mit der "Festplatte"
> nicht mitbekommt, dass die Platte 4k-Sektoren hat. Sie sie wird dann vom
> Installer wie eine mit 512-Byte-Sektoren partitioniert.

Kannst du nicht die Sektor Größe manuell angeben? Hast du in der VM auch 
die korrekten Settings (SSD flag, IDE vs SATA ...) angegeben?

von Uhu U. (uhu)


Lesenswert?

Läubi .. schrieb:
> Hast du in der VM auch die korrekten Settings (SSD flag, IDE vs SATA ...)
> angegeben?

Es ist eine SATA, aber es war IDE eingestellt - also nicht richtig.

Ich hatte einfach die Mint-Installation in der VB ablaufen lassen, ohne 
mich mit manueller Partitionierung auseinanderzusetzen.

von Uhu U. (uhu)


Lesenswert?

Die Einstellung SATA hat nichts geändert - die neu angelegte sda2 ist 
noch immer um 1024 Byte misaligned.

von Uhu U. (uhu)


Lesenswert?

Mit dem Partition-Editor der Mint 17-Installation kann man zwar manuell 
partitionieren, aber als Lage einer Partition kann man nur Anfang oder 
Ende des freien Bereiches angeben.

Der Partition-Editor verhält sich in VB ziemlich störrisch - ich habe 
die Platte so nicht in einen Zustand bekommen, der eine 
System-Installation zulässt.

von Läubi .. (laeubi) Benutzerseite


Lesenswert?

Das Problem ist dan vermutlich die Größe der vorangegangenen Partition?

von Uhu U. (uhu)


Lesenswert?

Läubi .. schrieb:
> Das Problem ist dan vermutlich die Größe der vorangegangenen Partition?

Das glaube ich nicht, denn die Partition wird auf ganze MBs Länge 
eingestellt, womit es eigentlich passen müsste - tuts aber nicht.


Zwischenzeitlich habe ich Mint 17 64-Bit auf blanker Hardware 
installiert. Anschließend wieder mein olles Ubuntu 12.04 (von einer 
anderen Platte) gebootet und die Mint-Platte im Disk Utility angesehen:

Mint 17 kriegt das mit den 4k-Sektoren nicht automatisch gebacken - sda2 
ist wieder um 1024 Byte daneben.


Das Ubuntu 12.04 hatte ich auch automatisch auf eine 1TB-Platte mit 
4k-Sektoren installiert - sdx2 ist korrekt plaziert.

So sieht die auf blanker HW vom Installer automatisch partitionierte 
Mint 17-Platte aus:
sudo fdisk -l /dev/sda

Disk /dev/sdb: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x000d6e2f

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1   *        2048      499711      248832   83  Linux
/dev/sdb2          501758  1953523711   976510977    5  Extended
Partition 2 does not start on physical sector boundary.
/dev/sdb5          501760  1953523711   976510976   83  Linux


Interessant: Disks von Mint - das entspricht dem Disk Utility von Ubuntu 
12.04 - bringt keine Warnung.

Soll das etwa heißen, dass das Problem anderweitig gelöst wurde?

: Bearbeitet durch User
von Uhu U. (uhu)


Lesenswert?

Uhu Uhuhu schrieb:
> Interessant: Disks von Mint - das entspricht dem Disk Utility von Ubuntu
> 12.04 - bringt keine Warnung.

Disks von Mint ist nur ein Anzeige-Werkzeug, während Disk Utility 
zusätzlich eine Menge von Plattenverwaltungsfunktionen enthält.

fdisk -l in dem unter VB gebooteten Mint bringt auch keine Warnung:

sudo fdisk -l

Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
255 heads, 63 sectors/track, 121601 cylinders, total 1953525168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0x000d6e2f

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *        2048      499711      248832   83  Linux
/dev/sda2          501758  1953523711   976510977    5  Extended
/dev/sda5          501760  1953523711   976510976   83  Linux

: Bearbeitet durch User
von Konrad S. (maybee)


Lesenswert?

Uhu Uhuhu schrieb:
> fdisk -l in dem unter VB gebooteten Mint bringt auch keine Warnung:

Warum sollte er? Irgendwie bekommt er das mit den 4kByte-Sektoren nicht 
mit.

von Uhu U. (uhu)


Lesenswert?

Konrad S. schrieb:
> Warum sollte er?

Als die 4k Sektoren aufkamen, führten fehljustierte Partitionen zu 
empfindlichen Leistungseinbußen - deswegen die Fehlermeldung in fdisk.

Dass das Problem mittlerweile behoben ist, habe ich bislang noch 
nirgends gelesen, auch wenn die Tatsache, dass es seit neustem in den 
GUI-Tools nicht mehr moniert wird, einige Hoffnung weckt, dass es 
behoben ist. fdisk von Mint 17 hält es durchaus noch für bemerkenswert.

> Irgendwie bekommt er das mit den 4kByte-Sektoren nicht mit.

Das sicher nicht, denn dann wären die Daten auf der Platte nach dem 
ersten Schreibzugriff auf einen nicht vollständigen 4k-Sektor Matsch.

: Bearbeitet durch User
von Konrad S. (maybee)


Lesenswert?

Uhu Uhuhu schrieb:
>> Irgendwie bekommt er das mit den 4kByte-Sektoren nicht mit.
>
> Das sicher nicht, denn dann wären die Daten auf der Platte nach dem
> ersten Schreibzugriff auf einen nicht vollständigen 4k-Sektor Matsch.

Das handelt die Platte intern ab, aber eben

> Als die 4k Sektoren aufkamen, führten fehljustierte Partitionen zu
> empfindlichen Leistungseinbußen - deswegen die Fehlermeldung in fdisk.

Ich wollte zum Ausdruck bringen, dass fdisk beim Zugriff auf die ¨rohe¨ 
Platte von dem Wunsch nach 4kByte I/O-Size Kenntnis hat, beim Zugriff 
auf die virtualisierte Platte bzw. aus der VM heraus nicht. Wäre diese 
Information noch vorhanden, würde vmtl. auch die Partitionierung 
innerhalb der VM mit korrektem Alignment durchgeführt werden.

von Uhu U. (uhu)


Lesenswert?

Konrad S. schrieb:
> Das handelt die Platte intern ab, aber eben

Kannst du das belegen?

> Ich wollte zum Ausdruck bringen, dass fdisk beim Zugriff auf die ¨rohe¨
> Platte von dem Wunsch nach 4kByte I/O-Size Kenntnis hat, beim Zugriff
> auf die virtualisierte Platte bzw. aus der VM heraus nicht.

Du irrst. Die Platte kann als kleinste Einheit einen Sektor von 4k 
adressieren; die Sektoradressen beziehen sich auf 4k-Sektoren. Wenn man 
eine 4k-Platte mit einem OS-beschreibt, das nur 512/Sektor an die Platte 
schickt, dann hat die eben nur 1/4 Kapazität.

> Wäre diese Information noch vorhanden, würde vmtl. auch die
> Partitionierung innerhalb der VM mit korrektem Alignment durchgeführt
> werden.

Dumm nur, dass Mint sich auf blanker Hardware ganz genauso verhält...

von Konrad S. (maybee)


Lesenswert?

Ich muss mich korrigieren: Der Kernel handelt das ab.

Es wäre toll, wenn sich für das Alignment-Problem eine Lösung finden 
würde.

> Dumm nur, dass Mint sich auf blanker Hardware ganz genauso verhält...

Das ist wirklich übel!

von Rolf Magnus (Gast)


Lesenswert?

Uhu Uhuhu schrieb:
> Konrad S. schrieb:
>> Warum sollte er?
>
> Als die 4k Sektoren aufkamen, führten fehljustierte Partitionen zu
> empfindlichen Leistungseinbußen - deswegen die Fehlermeldung in fdisk.

Das lag vor allem auch daran, daß bei DOS-Partitionstabellen die erste 
Partition per Konvention an einer Position anfängt, die nicht 4k-aligned 
ist und das Alignment dadurch grundsätzlich falsch war, wenn man es 
nicht manuell überschrieben hat. Insbesondere bei Platten, die intern 
4k-Sektoren haben, aber über das Interface 512-Byte-Sektoren emulieren. 
Dann funktioniert alles, aber die Platte muss die Zugriffe immer 
zusammenstückeln. Vor allem ist das fatal, weil Dateisysteme oft auch 
mit 4k-Blöcken arbeiten, die dann aber zu den platteninternen 4k-Blöcken 
verschoben sind.

> Dass das Problem mittlerweile behoben ist, habe ich bislang noch
> nirgends gelesen, auch wenn die Tatsache, dass es seit neustem in den
> GUI-Tools nicht mehr moniert wird, einige Hoffnung weckt, dass es
> behoben ist.

Bei GUID-Partition-Tables sollte es nicht vorkommen.

Uhu Uhuhu schrieb:
> Device Boot      Start         End      Blocks   Id  System
> /dev/sda1   *        2048      499711      248832   83  Linux
> /dev/sda2          501758  1953523711   976510977    5  Extended
> /dev/sda5          501760  1953523711   976510976   83  Linux

Wenn ich mir diese Partitionstabelle anschaue, finde ich es etwas 
verwunderlich, dass das logische Laufwerk in Partition 2 gegenüber dem 
Start der Partition um 2 verschoben ist. So wie ich das sehe, ist aber 
das dessen Alignment korrekt und nur das von sda2 falsch. Das dürfte 
doch eigentlich nichts ausmachen, da das ja eh nur der Container für 
sda5 ist.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.