Mal noch eine ganz dumme Frage dazu:
Warum soll das mit VM besser funktionieren als bei einem nativen System - beide müssen doch mit der neuen, dem System unbekannten Hardware arbeiten - es kommen also IMHO für beide nur irgendwelche Standardtreiber in Frage?! Und die müssen im Falle der VM auch noch auf dem Umweg über das Host-System auf die Hardware zugreifen - also doch potentiell eher noch langsamer als nativ? Oder verstehe ich das falsch? Mein virtuelles XP scheint mir jedenfalls langsamer zu sein als das, was ich auf meinem alten Rechner nativ hatte. Oder mache ich da was falsch?
Jein ...
Klar klaut Virtualisierung Leistung. Aber das spielt heute nur noch in wirklich alten Umgebungen eine Rolle. Eher ist die Frage, wie sehr die Prozessoren sich langweilen, nicht, ob sie es tun.
Wird hier ja schon angesprochen, dass man 'lebende' physische Kisten prima virtualisieren kann. Nach VMware, egal ob Player, Workstation oder ESXi, geht das super Converter. Für MS-Kram gibt es dafür das kleine Tool Disk2VDH, welches eine unter Hyper V (und ich denke, ebenso unter VirtualPC) lauffähige VHD erzeugt.
Was die Treiber, egal ob VM oder MS, an geht, so werden diese zum einen teilweise während der Konvertierung mit eingebunden, so dass die Kisten zumindest startfähig sind und man etwas sieht. Für 'schön' gibt es dann noch die jeweligen Tools, welche dem Gast-OS vom Host per virtueller CD zur Verfügung gestellt werden. Das ist alles absolut kein Thema, und x-Tausendfach erprobt.
Primär-Logisch-Aktiv-Erste-Zweite-Dritte:
WinDoof bootet, wie JEDES System auf einer MBR-Platte, grundsätzlich von einer aktiven primären Partition.
Dies liegt daran, dass a) nur eine primäre Partition aktiv sein kann, und dass b) der erste Teil des BootLoaders in deren BootSector liegt. Alles andere ist dann natürlich OS-abhängig.
Weiterhin kann eine MBR-Platte nur vier primäre (und dann keine logische!) Partition mehr tragen, weil die Partitionstabelle einfach nur Platz für vier Einträge bietet. Quasi beliebig viele erweiterte Partitionen benötigen in dieser nur einen einzigen Eintrag, welcher auf deren erste verweist, wo wiederum eine Partitionstabelle existiert. Damit wird die erste Spur der ersten Seite verbraten, und der Bootsector rutscht dann eine Nummer nach hinten. Dafür verweist diese Partitionstabelle dann auf die zweite erweiterte Partition. Jene der zweiten auf die Dritte, und immer so weiter. Auch dies ist völlig unabhängig vom OS, und ganz einfach der alten Architektur geschuldet, bei welcher die 'Erfindung' erweiterter Partitionen den Schmerz der EInschränkungen etwas mildern sollte.
Alles, was anders aussieht, oder sich auch anders verhält, ist Bootmanagern jedweder Form geschuldet. Damit bekommt man am Ende auch bequem zweistellige Anzahlen primärer Partitionen auf eine Platte, von denen dann aber immer jeiweils nur bis zu vier sichtbar sein können. Alle weiteren Informationen halten die Bootmanager ansonsten meist in standardmäßig nicht genutzten Sectoren direkt hinter der Partitionstabelle. Damit hatte ich, als Virtualisierung noch ein Fremdwort war, auch mal 5 oder 6 verschiedene Windows-Systeme auf einer Platte, welche alle bootfähig waren und immer ihr eigenes C: hatten. Den Rest hatte der Bootmanager halt immer sauber verborgen.
Und mal ehrlich, ob C: nun C: heißt, oder sich dev0 nennt, ist doch ziemlich wurscht. Der Unterschied ist eher, dass dev0 immer dev0 ist und bleibt, man WinDoof am Ende aber alles und jede partition als C: oder D: verkaufern kann. Es macht halt nur unter Umständen 'etwas' Aufwand, ihm dies so beizubringen.
@Tomas: Je genauer Du sagst, worum es eigentlich im Kern geht, um so treffender können auch die Tips und Hinweise sein. Kannst mir dazu auch gern eine PN schreiben, oder mich einfach anrufen.
