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.
Gast
#3705948
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!
./. 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.
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.
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?
Angehängte Dateien:
-
PartitionMisaligned.png
(17 KB)
Evtl. kannst du die Partition mit (g)parted verschieben. Innerhalb einer VM mit zusätzlich eingebundener "Festplatte" über eine SystemRescue-CD booten.
Es handelt sich nicht um eine "Festplatte", sondern um eine Festplatte, eine echte.
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".
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.
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. :-(
Die Platte auf echter Hardware installieren und dann erst an die VM koppeln, würde ich mal sagen. Ich probiers morgen aus.
Gast
#3738839
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".
Gast
#3738904
./. 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?
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?
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.
Die Einstellung SATA hat nichts geändert - die neu angelegte sda2 ist noch immer um 1024 Byte misaligned.
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.
Das Problem ist dan vermutlich die Größe der vorangegangenen Partition?
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?
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
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.
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.
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.
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...
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!
Gast
#3742798
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.