Wahrscheinlich banale Frage zur Sicherheit:
Ich habe die Workstation 10.0.7, mein Host ist Win 7 x64. Alle bisherigen VMs sind auch Win 7 x64, XP habe ich ausrangiert.
Ich muss jetzt 32 bit Systeme für Minitest verwenden und möchte "Win 7 32" und ev. 8 und 10 (32 bit) als VMs aufbauen.
Kurze Frage:
Da sollte ja eigentlich nicht viel schiefgehen - oder sind Fallen für simple Anwender wie mich zu erwarten?
Grüsse
Die Foren-SW läuft ohne erkennbare Probleme. Sollte doch etwas nicht funktionieren, bitte gerne hier jederzeit melden und wir kümmern uns zeitnah darum. Danke!
Win 7 x 64 host: Win 7/8/10 32 als Guest?
Dayworker hat geschrieben:Windows 10 dürfte für deine WS10.0.7 doch zum Problem werden. Offizieller Support dafür wurde erst bei der WS12 hinzugefügt. Wenn man als Gast-Typ jedoch "Windows 8" einträgt, sollte sich Win10 trotzdem installieren lassen.
Danke für den wichtigen Hinweis. Gilt das auch für die 64-bit Versionen? (Win 10 ist aber derzeit letzte Option, weil auch anderes nicht läuft)
-
Dayworker
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Ob 32 oder 64bit spielt für VMware meines Wissens keine Rolle bzw kann ich mich an keinen Fall erinnern, bei dem nur eine von beiden Versionen unterstützt wurde. Entweder ist ein Gast-OS offiziell supportet oder halt nicht. Das man die meisten OS trotzdem mit einigen Kniffs installieren kann, sei hier nur am Rande und der Vollständigkeit halber erwähnt.
Die einzige inzwischen nicht mehr wirklich als problematisch zu nennende Abhängigkeit betrifft weiterhin alle 64bittigen-Gäste. Ohne aktivierte HW-Virtualisierung in der CPU laufen diese bei VMware nicht, obwohl dies auf einem 64bittigen Host-OS eigentlich ohne Probleme zu realisieren wäre. VMware ist sich aber zumindest bisher in dieser Richtung treu geblieben, daß es 64bittige Gäste in allen Produkten nur mit aktiver HW-VT gibt. Bei allen halbwegs aktuellen CPUs ist HW-VT immer an Bord und selbst die neuen Atom-SOCs haben dazugelernt.
Die einzige inzwischen nicht mehr wirklich als problematisch zu nennende Abhängigkeit betrifft weiterhin alle 64bittigen-Gäste. Ohne aktivierte HW-Virtualisierung in der CPU laufen diese bei VMware nicht, obwohl dies auf einem 64bittigen Host-OS eigentlich ohne Probleme zu realisieren wäre. VMware ist sich aber zumindest bisher in dieser Richtung treu geblieben, daß es 64bittige Gäste in allen Produkten nur mit aktiver HW-VT gibt. Bei allen halbwegs aktuellen CPUs ist HW-VT immer an Bord und selbst die neuen Atom-SOCs haben dazugelernt.
Bericht (falls mal jemand drüber stolpert):
Nach langem Leiden geschafft ..
1. Problem: Die Startmaske von VM, in der Windows Typ und Lizenzkey abgefragt werden, ist anscheinend etwas sensibel beim Wechsel zwischen den Eingabefeldern. Jedenfalls habe ich es geschafft, hier einen OS-Typ zu installieren, den ich eigentlich nicht wollte und nicht lizenziert hatte ..
2. Aus irgendeinem Grund hat sich der zugewiesene RAM von 4 GB auf 1 GB reduziert; im OS war auch nur 1 GB Auslagerungsdatei definiert. Jeder Zugriff und Update war daher unendlich langsam.
3. Durch das Hin- und her waren die VMDK-Files schon reichlich defragmeniert, also Platte defragmentieren.
4. Und nach dem Update des SP1 bin ich dann noch in den Fehler "MS KB3102810" gerannt - Updatesuche läuft ewig mit 1 GB RAM und 100% CPU ohne Fortschritte.
Wenn man nun die Punkte 1-4 durchmischt kommt man auf den Zeitaufwand, den ich verbraten habe ...
Meine (teils banalen) Erkenntnisse:
- OS-Typ sorgfältig kontrollieren
- RAM im Host und Guest sofort hochfahren
- KB3102810 beachten
Grüsse
Nach langem Leiden geschafft ..
1. Problem: Die Startmaske von VM, in der Windows Typ und Lizenzkey abgefragt werden, ist anscheinend etwas sensibel beim Wechsel zwischen den Eingabefeldern. Jedenfalls habe ich es geschafft, hier einen OS-Typ zu installieren, den ich eigentlich nicht wollte und nicht lizenziert hatte ..
2. Aus irgendeinem Grund hat sich der zugewiesene RAM von 4 GB auf 1 GB reduziert; im OS war auch nur 1 GB Auslagerungsdatei definiert. Jeder Zugriff und Update war daher unendlich langsam.
3. Durch das Hin- und her waren die VMDK-Files schon reichlich defragmeniert, also Platte defragmentieren.
4. Und nach dem Update des SP1 bin ich dann noch in den Fehler "MS KB3102810" gerannt - Updatesuche läuft ewig mit 1 GB RAM und 100% CPU ohne Fortschritte.
Wenn man nun die Punkte 1-4 durchmischt kommt man auf den Zeitaufwand, den ich verbraten habe ...
Meine (teils banalen) Erkenntnisse:
- OS-Typ sorgfältig kontrollieren
- RAM im Host und Guest sofort hochfahren
- KB3102810 beachten
Grüsse
-
Dayworker
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Sorry, aber deine Angaben machen so keinen Sinn. Hier mal ein kleines Begriffe-1x1 in der VMware-Welt:
Zu Problem 1)
Was meinst du also mit "Die Startmaske von VM"?
Hattest du bei der Gast-Erstellung am Ende die Abfrage mit der sinngemäßen Antwort "Nein nicht jetzt, später" beantwortet?
Falls nicht, hat VMware aus dem eingestellten ISO oder DVD-Laufwerk sich die Win-Version bezogen und dafür eine eigentlich gutgemeinte Funktion namens "Easy-Install" genutzt. Diese schlägt häufig fehl, besonders wenn ISO oder DVD gleich mehrere Win-Versionen und dazu auch noch als 32bit- oder 64bit-Version enthalten.
Die Eingabe des Gast-OS ist im Grunde nur dafür wichtig, damit die WS bei der Inst der VMware-Tools das richtige ISO einlegt.
Zu Problem 2)
Hattest du die Gast-Inst über Easy-Install erledigt?
Vermutlich ja, denn ansonsten würde es zu keiner unerwarteten Verkleinerung des Gast-RAM kommen.
Das ich dieses "Easy-Install" nicht schon vorher erwähnt hatte, liegt allein daran, daß ich vorher hauptsächlich mit anderen, inzwischen eingestellten VMware-Produkten unterwegs war und es dort einige dieser Automatiken nicht gab.
Zu Problem 3)
Fragmentierte VMDK-Files sind nur für vDISKs im normalerweise platzsparenden Sparse-Format (mitwachsend, growable) interessant. Wenn der Host über eine SSD verfügt, Finger weg von irgendwelchen Defragmentierungsläufen. Jeder Schreibvorgang verkürzt nur die Lebensdauer einer SSD.
Zu Problem 4)
Den KB-Eintrag "MS KB3102810" kenne ich nur hauptsächlich im Zusammenhang mit dem Win10-Icon im Systemstartbereich, das einem unbedingt Win10 aufdrängen will. Dafür gibt es unter anderem unter http://blog.ultimateoutsider.com/2015/08/using-gwx-stopper-to-permanently-remove.html ein Abhilfe. Wer unbedingt Win10 haben will, sollte sich direkt bei Winzigweich das Media Creation Tool laden. Damit kannst du neben der Version auch die Bitbreite unabhängig vom laufenden Windows einstellen.
Was meinst du mit "RAM im Host und Guest sofort hochfahren"?
Das vRAM im Gast verstehe ich ja noch, aber das Host-RAM läßt sich nur sinnvoll über das Stecken weiterer DIMMs erweitern. Die Auslagerungsdatei zu vergrössern, ist keine wirkliche Lösung.
- VMware = Entwickler diverser Virtualisierungsprodukte
- VM = Gast = Virtuelle Maschine
- WS = Abkürzung für VMware-Workstation
- Host = Rechner auf dem das VMware-Produkt installiert wurde
- vDISK = virtuelle Platte
- VMDK = Datenträger des Gast-OS
Zu Problem 1)
Was meinst du also mit "Die Startmaske von VM"?
Hattest du bei der Gast-Erstellung am Ende die Abfrage mit der sinngemäßen Antwort "Nein nicht jetzt, später" beantwortet?
Falls nicht, hat VMware aus dem eingestellten ISO oder DVD-Laufwerk sich die Win-Version bezogen und dafür eine eigentlich gutgemeinte Funktion namens "Easy-Install" genutzt. Diese schlägt häufig fehl, besonders wenn ISO oder DVD gleich mehrere Win-Versionen und dazu auch noch als 32bit- oder 64bit-Version enthalten.
Die Eingabe des Gast-OS ist im Grunde nur dafür wichtig, damit die WS bei der Inst der VMware-Tools das richtige ISO einlegt.
Zu Problem 2)
Hattest du die Gast-Inst über Easy-Install erledigt?
Vermutlich ja, denn ansonsten würde es zu keiner unerwarteten Verkleinerung des Gast-RAM kommen.
Das ich dieses "Easy-Install" nicht schon vorher erwähnt hatte, liegt allein daran, daß ich vorher hauptsächlich mit anderen, inzwischen eingestellten VMware-Produkten unterwegs war und es dort einige dieser Automatiken nicht gab.
Zu Problem 3)
Fragmentierte VMDK-Files sind nur für vDISKs im normalerweise platzsparenden Sparse-Format (mitwachsend, growable) interessant. Wenn der Host über eine SSD verfügt, Finger weg von irgendwelchen Defragmentierungsläufen. Jeder Schreibvorgang verkürzt nur die Lebensdauer einer SSD.
Zu Problem 4)
Den KB-Eintrag "MS KB3102810" kenne ich nur hauptsächlich im Zusammenhang mit dem Win10-Icon im Systemstartbereich, das einem unbedingt Win10 aufdrängen will. Dafür gibt es unter anderem unter http://blog.ultimateoutsider.com/2015/08/using-gwx-stopper-to-permanently-remove.html ein Abhilfe. Wer unbedingt Win10 haben will, sollte sich direkt bei Winzigweich das Media Creation Tool laden. Damit kannst du neben der Version auch die Bitbreite unabhängig vom laufenden Windows einstellen.
Was meinst du mit "RAM im Host und Guest sofort hochfahren"?
Das vRAM im Gast verstehe ich ja noch, aber das Host-RAM läßt sich nur sinnvoll über das Stecken weiterer DIMMs erweitern. Die Auslagerungsdatei zu vergrössern, ist keine wirkliche Lösung.
Danke für die detaillierte Antworten. Eigentlich weichen diese wenig von meinen ab.
zu 1, 2) Fenster, Easy-Install
- Einmal habe ich gewählt "Nicht jetzt, später". Das habe ich dann überhaupt nicht mehr zum Installieren gebracht.
- Easy-Install: Habe ich gewählt, und es sind mehrere Win-Versionen auf der DVD (aber alle 32 bit). Und daher anscheinend auch die unerwartete Verkleinerung ...
- Durch Anwahl der falschen Version habe ich auch die falsche Version installiert.
zu 3) Defrag
Ich habe die Daten auf eine normalen Laufwerk, nicht auf SSD.
zu 4) MS KB3102810
Bei mir ist es nach gelaufen ... - ob Zufall oder durch das KB mag offen bleiben. In diversen Blogs wird es aber erwähnt: teils positiv, teils negativ.
zu 5) "RAM im Host und Guest sofort hochfahren"?
Mit "im Host" meinte ich die Einstellung in WS, die der VM den Arbeitsspeicher zuweist. Ich hatte mit 4 GB gestartet, die wurden dann auf 1 GB zurückgesetzt (siehe oben) und dann habe ich es wieder hochgesetzt.
mit "im Gast" meinte ich die Auslagerungsdatei innerhalb der VM. Ich halte mich an eine alte Empfehlung, die Grösse der Auslagerungsdatei nicht automatisch, sondern fix einzustellen. Ob es klug ist oder nicht mag dahingestellt bleiben ...
Grüsse
Peter
zu 1, 2) Fenster, Easy-Install
- Einmal habe ich gewählt "Nicht jetzt, später". Das habe ich dann überhaupt nicht mehr zum Installieren gebracht.
- Easy-Install: Habe ich gewählt, und es sind mehrere Win-Versionen auf der DVD (aber alle 32 bit). Und daher anscheinend auch die unerwartete Verkleinerung ...
- Durch Anwahl der falschen Version habe ich auch die falsche Version installiert.
zu 3) Defrag
Ich habe die Daten auf eine normalen Laufwerk, nicht auf SSD.
zu 4) MS KB3102810
Bei mir ist es nach gelaufen ... - ob Zufall oder durch das KB mag offen bleiben. In diversen Blogs wird es aber erwähnt: teils positiv, teils negativ.
zu 5) "RAM im Host und Guest sofort hochfahren"?
Mit "im Host" meinte ich die Einstellung in WS, die der VM den Arbeitsspeicher zuweist. Ich hatte mit 4 GB gestartet, die wurden dann auf 1 GB zurückgesetzt (siehe oben) und dann habe ich es wieder hochgesetzt.
mit "im Gast" meinte ich die Auslagerungsdatei innerhalb der VM. Ich halte mich an eine alte Empfehlung, die Grösse der Auslagerungsdatei nicht automatisch, sondern fix einzustellen. Ob es klug ist oder nicht mag dahingestellt bleiben ...
Grüsse
Peter
-
Dayworker
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
deine 1 und 2)
Hattest du die Gast-Inst von CD oder als ISO angestossen?
Wenn unabhängig von "Nicht jetzt, später" die Inst vom ISO nicht klappt, ist in den meisten Fällen das ISO fehlerhaft. Die Einstellung des Gast-OS ist auch noch für das "Easy-Install" verantwortlich, ich würde generell ohne "Easy-Install" installieren, daß schon eindeutig die Nerven.
dein 3)
Wenn du eine vDISK vom Typ Sparse einrichtest oder einen Snapshot anlegst, der vDISK-Typ ist bei Snapshots unabhängig vom Ursprungstyp immer Sparse, muß die Reihenfolge der VMDK-Fragmente nicht mit den Host-Sektoren übereinstimmen. Es kann dir daher sehr leicht passieren, daß du mit deiner Host-Defragmentierung die VMDK-Fragmentierung nur noch weiter erhöhst. Wenn du, immer ausreichend Platz auf dem Host-Datenträger vorausgesetzt, in der Workstation den Defrag-Button anklickst, versucht diese die vorhandenen VMDK-Fragmente in eine möglichst sinnvolle Reihenfolge zu bringen. Erst danach macht die Host-Defragmentierung einen Sinn.
dein 4)
Der M$-KB-Eintrag ist wohl positiv, da er auch noch für die Server-OS gilt. Leider schweigt sich Winzigweich in meinen Augen etwas aus, was dort genau mit gefixt wird.
dein 5)
Die Änderung der vRAM-Zuweisung kam sicherlich durch das "Easy-Install".
Von der Empfehlung die Auslagerungsdatei fest einzustellen, halte ich überhaupt nichts. Wenn der RAM ausreicht, ist die Datei nur unnötig groß und wenn der RAM kurzzeitig klamm wird, ist die Grösse fest begrenzt und daher kontraproduktiv. Selbst ein normales M$-Update kann zu einem stärkeren Anschwellen der Datei führen und wenn die Grösse nicht ausreicht, kann Windows auch mal nen BSOD werfen. Das häufig genannte Argument, daß die Verwaltung der Auslagerungsdatei Rechenzeit kostet, dürfte in der heutigen Zeit mit mindestens Dual- oder Quadcore-CPUs auch immer weiter in den Hintergrund treten. Wenn ein Rechner zu lahm ist, pack ne SSD rein und die Möhre rennt in den meisten Fällen wieder.
Hattest du die Gast-Inst von CD oder als ISO angestossen?
Wenn unabhängig von "Nicht jetzt, später" die Inst vom ISO nicht klappt, ist in den meisten Fällen das ISO fehlerhaft. Die Einstellung des Gast-OS ist auch noch für das "Easy-Install" verantwortlich, ich würde generell ohne "Easy-Install" installieren, daß schon eindeutig die Nerven.
dein 3)
Wenn du eine vDISK vom Typ Sparse einrichtest oder einen Snapshot anlegst, der vDISK-Typ ist bei Snapshots unabhängig vom Ursprungstyp immer Sparse, muß die Reihenfolge der VMDK-Fragmente nicht mit den Host-Sektoren übereinstimmen. Es kann dir daher sehr leicht passieren, daß du mit deiner Host-Defragmentierung die VMDK-Fragmentierung nur noch weiter erhöhst. Wenn du, immer ausreichend Platz auf dem Host-Datenträger vorausgesetzt, in der Workstation den Defrag-Button anklickst, versucht diese die vorhandenen VMDK-Fragmente in eine möglichst sinnvolle Reihenfolge zu bringen. Erst danach macht die Host-Defragmentierung einen Sinn.
dein 4)
Der M$-KB-Eintrag ist wohl positiv, da er auch noch für die Server-OS gilt. Leider schweigt sich Winzigweich in meinen Augen etwas aus, was dort genau mit gefixt wird.
dein 5)
Die Änderung der vRAM-Zuweisung kam sicherlich durch das "Easy-Install".
Von der Empfehlung die Auslagerungsdatei fest einzustellen, halte ich überhaupt nichts. Wenn der RAM ausreicht, ist die Datei nur unnötig groß und wenn der RAM kurzzeitig klamm wird, ist die Grösse fest begrenzt und daher kontraproduktiv. Selbst ein normales M$-Update kann zu einem stärkeren Anschwellen der Datei führen und wenn die Grösse nicht ausreicht, kann Windows auch mal nen BSOD werfen. Das häufig genannte Argument, daß die Verwaltung der Auslagerungsdatei Rechenzeit kostet, dürfte in der heutigen Zeit mit mindestens Dual- oder Quadcore-CPUs auch immer weiter in den Hintergrund treten. Wenn ein Rechner zu lahm ist, pack ne SSD rein und die Möhre rennt in den meisten Fällen wieder.
zu Easy-Install)
Geplant hatte ich, "Nicht jetzt, später" von DVD laufen zu lassen. Aber nach dem Einlesen(?) der MAC-Adresse kam ich nicht weiter. war vielleicht mein Anwenderfehler.
easy-Install nicht easy:
Ja, scheint so
MS KB:
Jedenfalls habe ich auf meinem Host jetzt auch das Win10-Icon, dass ich vor Wochen eigentlich "weggeschalten" hatte. Scheint eine nicht geplante Nebenwirkung zu sein.
fixe Auslagerungsdatei:
Da gab es die Empfehlung/Kochrezept (noch zu XP Zeiten), die Auslagerungsdatei auf das 1.5-2 fache des RAM festzulegen, nachdem man vorher ordentlich defragmentiert hat. Das ergibt einen einzigen grossen Block, der schnell verwendet wird.
Wie gesagt, ob das damals richtig war und heute noch ist, ist wahrscheinlich nicht so eindeutig zu sagen.
Geplant hatte ich, "Nicht jetzt, später" von DVD laufen zu lassen. Aber nach dem Einlesen(?) der MAC-Adresse kam ich nicht weiter. war vielleicht mein Anwenderfehler.
easy-Install nicht easy:
Ja, scheint so
MS KB:
Jedenfalls habe ich auf meinem Host jetzt auch das Win10-Icon, dass ich vor Wochen eigentlich "weggeschalten" hatte. Scheint eine nicht geplante Nebenwirkung zu sein.
fixe Auslagerungsdatei:
Da gab es die Empfehlung/Kochrezept (noch zu XP Zeiten), die Auslagerungsdatei auf das 1.5-2 fache des RAM festzulegen, nachdem man vorher ordentlich defragmentiert hat. Das ergibt einen einzigen grossen Block, der schnell verwendet wird.
Wie gesagt, ob das damals richtig war und heute noch ist, ist wahrscheinlich nicht so eindeutig zu sagen.
Nachtrag: CD/DVD-Problem
Ich habe gemerkt, dass mein (echtes) CD/DVD-Laufwerk zu "knirschen2 beginnt, wenn ich die "VM 7 32" starte. Im Laufwerk ist nichts drinnen, es geht die ganze Zeit "quitsch-quitsch-tack". Wenn ich die VM beende, hört das auch auf.
Beim nächsten Start meiner Host-Maschine hat es da auch schon angefangen und der PC blieb hängen. Ich musste dem Stromschalter die Maschine killen.
Ich habe jetzt gesehen, das für alle meine "Win 7 x64" VMs die Konfiguration auf
"CD/DVD (SCSI): Auto detect"
steht. Für die x32 VM steht sie auf
"CD/DVD (SATA): Auto detect"
Kann das ein Grund sein für die Probleme? Kennst sich das laufwerk nicht mehr aus, was es sein soll?
Schönen Abend
Peter
Ich habe gemerkt, dass mein (echtes) CD/DVD-Laufwerk zu "knirschen2 beginnt, wenn ich die "VM 7 32" starte. Im Laufwerk ist nichts drinnen, es geht die ganze Zeit "quitsch-quitsch-tack". Wenn ich die VM beende, hört das auch auf.
Beim nächsten Start meiner Host-Maschine hat es da auch schon angefangen und der PC blieb hängen. Ich musste dem Stromschalter die Maschine killen.
Ich habe jetzt gesehen, das für alle meine "Win 7 x64" VMs die Konfiguration auf
"CD/DVD (SCSI): Auto detect"
steht. Für die x32 VM steht sie auf
"CD/DVD (SATA): Auto detect"
Kann das ein Grund sein für die Probleme? Kennst sich das laufwerk nicht mehr aus, was es sein soll?
Schönen Abend
Peter
-
Dayworker
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Nö, ob da nun "CD/DVD (SCSI): Auto detect" oder "CD/DVD (SATA): Auto detect" steht, spielt dafür keine Rolle. Der entscheidende Punkt ist das Auto detect am Ende. Damit sagst du der VM, daß das im Host-Rechner steckende CD/DVD-Laufwerk der VM gehört und diese testet wie jedes OS alle Datenträger auf Veränderungen bzw neue Medien. Da die Einbindung eines physischen CD/DVD-Laufwerkes auch mit kleinen Performanceeinbrüchen bestraft wird und ISOs wesentlich praktischer sind, entferne entweder das physische Laufwerk oder stell auf ein ISO um.
Zurück zu „VMware Workstation und VMware Workstation Pro“
Wer ist online?
Mitglieder in diesem Forum: Majestic-12 [Bot] und 16 Gäste