Virtualisierung eines laufenden Systems.

[feluxe]

Hallo zusammen,

ich würde gern meine laufendes OS (W7 Pro x64) in ein VM Image umwandeln, um es später auf einem Linux Host als Guest zu booten.

Mein Laptop, auf dem das Ganze laufen soll hat folgende Hardware:

Intel i7-3520M @ 2.9GHz (2 Cores / 4 Threads)
Intel HD 4000 Grafik
16GB Ram
256GB SSD

Ich habe bereits ein Testdurchlauf hinter mir. Und zwar habe ich Win7 aus laufendem Betrieb mit VMware Converter in eine VM konvertiert und anschließend mit dem Player gestartet. Anfänglich hatte ich Probleme mit den Eingabegeräten, welche ich durch Deinstallation der richtigen Treiber im Abgesicherten Modus beheben konnte. Nachdem die Guest Tool installiert waren, lief die VM ganz gut.
Leider bin ich mir sehr unsicher, was die Einstellung (vor allem CPU) angeht und da ich die VM nur einmal einrichten kann, bevor ich das System Platt mache, ist es mir wichtig, dass die Einstellungen gut passen und auf dem Linux Host gut laufen. Hat vielleicht jemand ein Paar Ratschläge für mich? Das wäre sehr hilfreich!

Speziell diese Optionen überfordern mich:

- Number of virtual sockets
- Number of Cores per Socket
- Disk Controller
- Einstellungen unter "Advanced Options" > "Post Conversion"
- CPU Throttling

Gibt es irgendwelche Services, die man unbedingt deaktivieren sollte?

Ich hoffe ihr könnt mir weiterhelfen!

Edit:
Was die Rechenpower der VM angeht, wäre es mir am liebsten, wenn Host und Guest jeweils die Hälfte der Ressourcen zur Verfügung hätten.

[mbreidenbach]

Die benötigte Anzahl der CPU Cores hängt von den Anwendungen ab.

Ich würde es so angehen daß man erstmal wenig Ressourcen zuweist und schaut wie's denn so läuft.

Auf jeden Fall Treiber für nicht mehr vorhandene Hardware deinstallieren und auch im Gerätemanager aufräumen.
Dabei https://support.microsoft.com/en-us/kb/315539 berücksichtigen.

Man kann dann uch noch ein paar Sachen abstellen... Defragmentirung in VMs ist normalerweise ziemlich sinnlos; ebenso Screensaver (außer 'blank screen') die nur CPU fressen.

Für virtualisierte Desktops gibts ein best practice guide...*such*...

http://www.vmware.com/resources/techresources/10157

[feluxe]

Vielen Dank schon mal!
Ich habe alle treiber Deinstalliert und danach die Guest-Tools noch mal neu installiert. Dann habe ich die Optimierungs Software installiert.
Jeztzt läuft alles noch flüssiger. Gut das zu wissen!

Die benötigte Anzahl der CPU Cores hängt von den Anwendungen ab.

Da beide OS, also der Linux Host und der Windows Guest gleichermaßen benutzt werden sollen, hätte ich gesagt, dass es am besten wäre, wenn ich die Ressourcen 50:50 verteilen könnte oder dynamisch falls möglich. Aber so weit ich weiß muss man immer eine feste Anzahl an CPUs und eine feste Menge RAM zuweisen?

Ich würde es so angehen daß man erstmal wenig Ressourcen zuweist und schaut wie's denn so läuft.

Das Problem ist, dass ich den Rechner platt machen muss, um Linux zu installieren. Ich muss die Einstellungen für das VM Image so schnell es geht festlegen und dann alles formatieren. Ich muss mich also entscheiden. Das Image was ich bis jetzt erstellt habe hat 1 Socket mit 2 Kernen. Ich denke das müsste die Hälfte der CPU Power sein, weil meine CPU insgesamt 2 Cores und 4 Threads hat. Oder sollte ich der VM lieber nur einen Core zuteilen?

[JustMe]

Du musst die Einstellungen fuer das VM Image nicht festlegen...

Das laesst sich im Nachhinein (bei heruntergefahrener Virtueller Maschine) alles nach Gutduenken aendern. (OK, Windows-Aktivierungsorgien jetzt mal unbeachtet gelassen; das haengt von der verwendeten Lizenz ab.)

Grundsaetzlich solltest Du Dich vielleicht von der Vorstellung trennen, dass beim Player die Ressourcen der Hardware zwischen Host und Guest unbedingt "aufgeteilt" werden muessten.

"Konfiguration" bedeutet NICHT "feste Zuweisung" bzw. "Reservierung".

Der Player bzw. die ausgefuehrte VM ist im Host einfach eine gestartete Applikation, so wie unter Windows vielleicht das Notepad, oder unter Linux, wasweissich, vielleicht Gimp. Und insofern kabbelt sich die VM zusammen mit allen anderen ausgefuehrten Prozessen um die Ressourcen der Hardware, deren Verwaltung jedoch dem Hypervisor obliegt. Soll heissen: Diese "Applikation" versucht ebenjene Ressourcen fuer sich zu beanspruchen, die einerseits gewuenscht (d.h. in der VM-Konfiguration eingestellt) und andererseits vom Host bereitgestellt werden.

Beim Start der VM werden die konfigurierten Ressourcen (CPU und RAM) eben NICHT fuer die VM reserviert bzw. dem Host weggenommen, und selbst wenn man z.B. 2GB RAM einstellt, werden die nicht sofort belegt. (Nochmal OK, da kann man zwar viel konfigurieren, aber das sollte man erst tun, wenn man die Zusammenhaenge auch verstanden hat.)

Grundsaetzlich sollte eine VM immer nur soviel konfiguriert bekommen, wie sie BENOETIGT, und nicht, wieviel MOEGLICH ist. Die VM mit 2 Kernen auszustatten, kann bei einem System mit nur DualCore (Hyper-Threading-Nachgeburten sind KEINE echten Kerne) bereits zuviel sein.

[feluxe]

Du musst die Einstellungen fuer das VM Image nicht festlegen...

Auch wenn mir VMware Converter folgende Warunug anzeigt?

Changing the virtual CPU configuration after the guest operating system is installed migth cause the virtual machine to become unstable.

Wenn die Nachricht keine Rolle spielt, kann ich natürlich ganz easy alles fertig machen und mich um die VM Einstellungen später kümmern wenns drauf ankommt.

Grundsätzlich solltest Du Dich vielleicht von der Vorstellung trennen, dass beim Player die Ressourcen der Hardware zwischen Host und Guest unbedingt "aufgeteilt" werden muessten.

Verhalten sich andere Tools anders bzw. vorteilhafter? Ich bin nämlich noch nicht sehr zufrieden mit der Performance der VM. Wenn ich daran denke jeden tag 8 Stunden damit zu arbeiten, sollte das ganze schon möglichst gut laufen...

Grundsaetzlich sollte eine VM immer nur soviel konfiguriert bekommen, wie sie BENOETIGT, und nicht, wieviel MOEGLICH ist. Die VM mit 2 Kernen auszustatten, kann bei einem System mit nur DualCore (Hyper-Threading-Nachgeburten sind KEINE echten Kerne) bereits zu viel sein.

Und was macht man wenn manchmal der Host möglichst viel benötigt und manchmal der Guest? Natürlich benötige ich für jedes OS möglichst viel Leistung, nur eben manchmal mehr für das eine OS und manchmal mehr für das andere. Darum bin ich ja auf 50:50 gekommen. Aber wenn die Einstellungen weiterhin änderbar sind, experimentiere ich später damit.
Momentan macht mir am meisten Sorgen, dass die VM nicht gut genug performen könnte, um auf Dauer damit zu arbeiten, ganz egal wie gut sie eingestellt ist.

[~thc]

Ich bin nämlich noch nicht sehr zufrieden mit der Performance der VM. Wenn ich daran denke jeden tag 8 Stunden damit zu arbeiten, sollte das ganze schon möglichst gut laufen...

Darf ich mal nach der zugrunde liegenden Motivation fragen? Wenn du acht Stunden vor einem möglichst performanten System sitzen möchtest, warum nicht vor dem nativen Windows 7? Oder andersherum: Wenn die einzige VM acht Stunden performant laufen soll, was bleibt dann für das Host-OS zu tun?

[Dayworker]

Du hast eine Dualcore-CPU mit HT. In diesem Fall würde ich die VM nur mit maximal zwei CPUs, ob 1 Sockel mit Dualcore oder 2 Sockel mit Singlecore spielt eigentlich nur für die notwendige SW-Lizenzierung eine Rolle, konfigurieren. Mehr macht kein Sinn, denn die für die logischen Kerne anliegende Arbeit müssen ja doch wieder von den physikalisch vorhandenen Kernen übernommen werden.

Die Converter-Warnung beruht daher, daß ältere Windows-Versionen je nach Sockelanzahl einen anderen HAL nutzten. Wenn man diesen jedoch änderte, wurde auch sämtliche HW in der VM neu erkannt und eine OS-Reaktivierung wurde erforderlich.

Für den Host ist die VM ein Programm wie jedes andere auch. Wenn dieses CPU-Leistung anfordert, wird es diese auch bekommen, solange das Host-OS nicht seinerseits nach Leistung fragt. In diesem Fall gewinnt logischerweise immer das Host-OS. Mit Linux als Host-OS solltest du dich auch mit propitärer, also nicht im Quelltext vorliegender SW vertraut machen. VMware hat sein festes Release-Schema und hinkt je nach Kernel-Version dann deutlich hinterher. Das kann zu unerwarteteten Problemen bei den VMware-Kernelmodulen führen, da sich diese dann ggf ohne zum eingesetzten Kernel passenden Patch nicht kompilieren lassen und das Patchen kann und wird dich bei jedem Linux-Update fortan begleiten, bis VMware eine neuere Produktversion herausgibt. Da die Kernel-EW jedoch üblicherweise im 3-Monatsrhythmus erfolgt, kannst du dir jetzt schon ausrechnen, ab wann du einen entsprechenden Patch brauchst. Linux als Host-OS macht also nur Sinn, wenn du den ausschließlichen Einsatz von LTS-Versionen planst. RR-Distributionen wie Linux-Mint mit ihren ständig aktualisierten Kerneln machen als Host-OS keine Freude, denn nach jedem Update kann die notwendige Kompilierung der Kernel-Module wieder fehlschlagen und wenn man auf eine funktionale VM angewiesen ist...

[feluxe]

Darf ich mal nach der zugrunde liegenden Motivation fragen? Wenn du acht Stunden vor einem möglichst performanten System sitzen möchtest, warum nicht vor dem nativen Windows 7

Als Entwickler möchte ich am liebsten mit LInux arbeiten, weil Linux ein mehr Command Line orientiertes Betriebssystem ist als Windows und die Art wie man dort auf OS Level arbeitet eher mit der Art wie ich auf Projekt Level arbeite übereinstimmt. Leider gibt es Programme unter Windows auf die ich nicht verzichten kann und die in meinem "Workflow" immer wieder auftauchen. Am liebsten würde ich komplett auf die VM verzichten, aber das geht leider noch nicht.

Oder andersherum: Wenn die einzige VM acht Stunden performant laufen soll, was bleibt dann für das Host-OS zu tun?

Beide OS sollen parallel laufen, wenn ich am Rechner bin, sodass ich jeder Zeit von Workstation zu Workstation switchen kann.

Du hast eine Dualcore-CPU mit HT. In diesem Fall würde ich die VM nur mit maximal zwei CPUs, ob 1 Sockel mit Dualcore oder 2 Sockel mit Singlecore spielt eigentlich nur für die notwendige SW-Lizenzierung eine Rolle, konfigurieren. Mehr macht kein Sinn, denn die für die logischen Kerne anliegende Arbeit müssen ja doch wieder von den physikalisch vorhandenen Kernen übernommen werden.

Das hört sich plausibel an!

Die Converter-Warnung beruht daher, daß ältere Windows-Versionen je nach Sockelanzahl einen anderen HAL nutzten. Wenn man diesen jedoch änderte, wurde auch sämtliche HW in der VM neu erkannt und eine OS-Reaktivierung wurde erforderlich.

Gut das zu wissen, danke! Dann kann ich ja ohne schlechtes Gewissen einfach loslegen.

Mit Linux als Host-OS solltest du dich auch mit propitärer, also nicht im Quelltext vorliegender SW vertraut machen.

Meinst du ich soll mir ein anderes VM Tool besorgen? Weil die schneller Patches bereitstellen? Oder aus welchem Grund soll ich mich nach closed source Software umsachen? Das habe ich jetzt nicht ganz verstanden?

VMware hat sein festes Release-Schema und hinkt je nach Kernel-Version dann deutlich hinterher. Das kann zu unerwarteteten Problemen bei den VMware-Kernelmodulen führen, da sich diese dann ggf ohne zum eingesetzten Kernel passenden Patch nicht kompilieren lassen und das Patchen kann und wird dich bei jedem Linux-Update fortan begleiten, bis VMware eine neuere Produktversion herausgibt. Da die Kernel-EW jedoch üblicherweise im 3-Monatsrhythmus erfolgt, kannst du dir jetzt schon ausrechnen, ab wann du einen entsprechenden Patch brauchst. Linux als Host-OS macht also nur Sinn, wenn du den ausschließlichen Einsatz von LTS-Versionen planst. RR-Distributionen wie Linux-Mint mit ihren ständig aktualisierten Kerneln machen als Host-OS keine Freude, denn nach jedem Update kann die notwendige Kompilierung der Kernel-Module wieder fehlschlagen und wenn man auf eine funktionale VM angewiesen ist...

Alter Schwede, das war mir so nicht bewusst. Hätte jetzt auf anhieb kein LTS Linux installiert. Eine andere Möglichkeit wäre natürlich ein non LTS Linux zu installieren und den OS Patch Cycle an den VMware Patch Cycle anzupassen. Das ginge natürlich nur, wenn man seitens VMware ausreichend Informationen bereitgestellt bekommt, bis zu welchen Kernel man "Hochpatchen" darf. Was hälst du davon?

[~thc]

Die Kombination VMWare Player und Linux Host OS kann man nur bei Distributionen empfehlen, deren Kernel-Patch-Zyklus extrem konservativ ist (z.B. Debian) - und selbst da kann es dann irgendwann zu Problemen kommen.

Auch wenn es "psychologisch" nicht deinem Wunsch entgegenkommt, wirst du mittelfristig mit Windows als Host-OS und Linux als VM weniger Mühe haben.

[Dayworker]

Meine Aussage "Mit Linux als Host-OS solltest du dich auch mit propitärer, also nicht im Quelltext vorliegender SW vertraut machen" bedeutet nichts anderes, daß man sich auf einige Probleme gefaßt machen muß, wenn man unter Linux nicht im Quelltext vorliegende SW einsetzt und Virtualisierung setzt prinzipbedingt extrem tief im System an. Wenn die Kernel-Hacker der Meinung sind, mal wieder grundlegende Abschnitte im Kernel umzuschreiben, klappt meist - also nicht immer - die Rekompilierung der Kernelmodule nicht mehr. Falls du also unbedingt eine RR-Distribution einsetzen willst, bist du mit dem durch die Kernel-Hacker im Zuge der Kernel-EW mitgepflegten KVM besser bedient. Aber VMware hat weiterhin einige Vorzüge hinsichtlich problemloser Ausführung zwischen allen VMware-Produkten hinweg. Es ist also kein Problem, eine unter Workstation/Player12 erstellt VM auf dem Server-Produkt vSphere6 auszuführen. Man kann sogar einige Vorkehrungen hinsichtlich Netzwerkinterface (vSphere kennt von Haus aus nur Bridge) und dessen Interfacebezeichnung treffen, damit der Umgang mit der VM einfacher wird. Man legt beispielsweise unter vSphere einen vSwitch mit dem Namen "Bridge" oder falls man in den VMware-Desktopprodukten mit dem VMware-Custom-Interface und "VMnet0" gearbeitet hat, einen gleichnamigen vSwitch an. Die VM versteht dann sofort, welche Netzwerkkarte des vSphere-Hosts genutzt werden soll. Das schöne bei allen VMware-Produkten ist, daß nur die Einträge ausgewertet werden, die von der momentanen Plattform verstanden werden und alles andere wird ignoriert.


Von "Ein non LTS Linux zu installieren und den OS Patch Cycle an den VMware Patch Cycle anzupassen" halte ich überhaupt nix. Du willst ja mit beiden OS arbeiten und von daher müssen auch beide OS von bekanntgewordenen Sicherheitslücken befreit werden. Du kommst also um ein Update nicht herum, zumal VMware stellenweise nur ein Release pro Jahr raushaut. VMware unterstützt bei Linux eigentlich immer nur die zum Releasezeitraum ausgelieferte Kernel-Version der jeweiligen Distributionen. Keine Distribution liefert aber meines Wissens eine Liste, wie die beim neuesten Kernel bekanntgewordenen Probleme in ihre eigenen Kernel-Version zurückportiert wurden. Da müßte man also selbst ein Diff machen und dazu auch noch die Eigenheiten einiger Distributionen (Beispiel Umnummerierung der Kenrnel-Version bei Ubuntu14.04LTS) berücksichtigen. Vielleicht wird die Situation einfacher zu verstehen, wenn du jede neue Kernel-Version als ein komplett neues Betriebssystem ansiehst.
Einige Linux-Distributionen haben aber angefangen, Patches in ihr Repository aufzunehmen, damit die Rekompilierung der VMware-Kernelmodule nach einer Kerneländerung nicht mehr fehlschlägt.
Im grossen und ganzen bist du mit einer LTS-Version deutlich besser bedient, ist halt einfach pflegeleichter...