"C:\Programme (x86)\VMware\VMware Workstation\vmware-vdiskmanager" -R "D:\Viritual Machines\Windows 7 x64\Windows 7 x64.vmdk"
System kann Datei nicht finden kommt.
Dachte ich mir doch.
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!
CD DVD Laufwerke werden angezeigt, aber gehen nicht.
-
Dayworker
- King of the Hill
- Beiträge: 13656
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Okay, aber du findest auch den "vdiskmanager" im WS-Programmeordner oder versteckt der sich bei der WS9.02 an einem anderen Ort. Eventuell hat sich Windows aber auch wieder kleinlich und scheitert an einer fehlenden EXE-Endung...
Versuch mal nur die Eingabe in der Eingabeaufforderung:
Wenn das funktioniert, sollte eigentlich auch folgendes gehen oder einer der beiden Pfade stimmt nicht:
Versuch mal nur die Eingabe in der Eingabeaufforderung:
Code: Alles auswählen
"C:\Programme (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe"Wenn das funktioniert, sollte eigentlich auch folgendes gehen oder einer der beiden Pfade stimmt nicht:
Code: Alles auswählen
"C:\Programme (x86)\VMware\VMware Workstation\vmware-vdiskmanager.exe" -R "D:\Viritual Machines\Windows 7 x64\Windows 7 x64.vmdk" Nee geht nicht.. .kann immer noch nix finden. Ja der vdiskmanager ist definitiv an diesem Ort.
Kann es sein, dass VMware, bzw. das Gastsystem C nicht findet, weil es auf einer PCIe SSD liegt und das Gastsystem wegen fehlender Treiber nicht darauf zugreifen kann?
Acronis konnte auch nicht darauf zugreifen. Daher musste ich extra eine Windows PE mit Acronis erstellen und die Treiber integrieren. Ich installiere jetzt einfach mal die Treiber im Gastsystem.
Ich habe auch so keinen Zugriff auf meine physikalisches W7 auf C vom Gastsystem aus. Ich kann auch nicht meiner Heimnetzgruppe beitreten. Ich kann lediglich Dateien in mein Gastsystem hineinkopieren und dann installieren, trotz Freigaben auf meinem Hauptsystem.
Danke es liegt daran, dass es überhaupt nicht zugreifen kann.
Nachtrag: Auch die RevoDrive3 X2 Driver haben nix gebracht. Hab in den Netzwerkeinstellungen gesucht, Netzwerkdiagnosen...etc. gemacht, doch das Gastsystem kann nicht auf mein reales C zugreifen aber auch auf sonst keine Partition auf meinem Rechner.
Gruß Anreni
Kann es sein, dass VMware, bzw. das Gastsystem C nicht findet, weil es auf einer PCIe SSD liegt und das Gastsystem wegen fehlender Treiber nicht darauf zugreifen kann?
Acronis konnte auch nicht darauf zugreifen. Daher musste ich extra eine Windows PE mit Acronis erstellen und die Treiber integrieren. Ich installiere jetzt einfach mal die Treiber im Gastsystem.
Ich habe auch so keinen Zugriff auf meine physikalisches W7 auf C vom Gastsystem aus. Ich kann auch nicht meiner Heimnetzgruppe beitreten. Ich kann lediglich Dateien in mein Gastsystem hineinkopieren und dann installieren, trotz Freigaben auf meinem Hauptsystem.
Danke es liegt daran, dass es überhaupt nicht zugreifen kann.
Nachtrag: Auch die RevoDrive3 X2 Driver haben nix gebracht. Hab in den Netzwerkeinstellungen gesucht, Netzwerkdiagnosen...etc. gemacht, doch das Gastsystem kann nicht auf mein reales C zugreifen aber auch auf sonst keine Partition auf meinem Rechner.
Gruß Anreni
-
continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
vdiskmanager -R ist kaputt seit ein paar Versionen.
Wenn beide dateien vorhanden sind - dann extrahier mal den embedded descriptor und poste den - siehe
http://sanbarrow.com/vmdk-howtos.html#editvmdk
Wenn beide dateien vorhanden sind - dann extrahier mal den embedded descriptor und poste den - siehe
http://sanbarrow.com/vmdk-howtos.html#editvmdk
-
Dayworker
- King of the Hill
- Beiträge: 13656
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Kann es sein, daß in dir die Angst hochsteigt und du jetzt Flüchtigkeitsfehler machst?
Das Gast-OS interessiert es herzlich wenig, was auf dem Host abläuft, da der Gast keinen direkten Datenträgerzugriff auf den Host hat. Einzigste Ausnahme ist, wenn dein Gast mit physikalischen Datenträgerzugriff auf eine Platte konfiguriert wurde. Aber im Falle des phys.Datenträgerzugriffs wäre es eh tödlich, wenn Host und Gast gleichzeitig auf denselben Datenbestand zugreifen könnten. Ausgehend von deinem verlinkten "vmware.log" ist das jedoch nicht der Fall, da du dann keine Sparse-Disk haben könntest.
Demzufolge kannst du die vDISK nur vom Host aus und bei komplett runtergefahrener VM reparieren, ein Suspend über WS/Player reicht hier nicht aus und Hibernation im Gast wäre auch unproduktiv.
Das Gast-OS interessiert es herzlich wenig, was auf dem Host abläuft, da der Gast keinen direkten Datenträgerzugriff auf den Host hat. Einzigste Ausnahme ist, wenn dein Gast mit physikalischen Datenträgerzugriff auf eine Platte konfiguriert wurde. Aber im Falle des phys.Datenträgerzugriffs wäre es eh tödlich, wenn Host und Gast gleichzeitig auf denselben Datenbestand zugreifen könnten. Ausgehend von deinem verlinkten "vmware.log" ist das jedoch nicht der Fall, da du dann keine Sparse-Disk haben könntest.
Demzufolge kannst du die vDISK nur vom Host aus und bei komplett runtergefahrener VM reparieren, ein Suspend über WS/Player reicht hier nicht aus und Hibernation im Gast wäre auch unproduktiv.
Ja hast reicht, so langsam glaube ich an Horrorgeschichten.. .zu Teufel warum geht das nicht.
Dein letzter Satz verwirrt mich nun aber. Ich habe das CMD im Gast benutzt wie im Beitrag beschrieben. Das ist doch korrekt? VM ist gestartet und Gast ist gebootet.
embedded descriptor ?? Da muss ich mich dann wieder mit befassen. Au Backe, wird wohl wieder so ein Ding wie der log. ...Kann das denn nicht einfach mal funktionieren?
Habe jetzt bestimmt 6 Jahre VMware nicht mehr benutzt, weil ich eigentlich schneller ein System neu aufgesetzt habe wie es mit VMware in Ruhe zu konfigurieren. Und warum, weil diese ganzen VM Geschichten nicht richtig funktionierten. Na nach dieser langer Zeit dachte ich die Sache wäre nun einfacher. Und was ist, es klappt hinten und vorne nicht. Was soll so ein Mist? Ein Trost bleibt die Mitstreiter sind noch übler.
Langsam hab ich die Nase voll. Danke an alle .. .und vor allem an Dayworker für deine Mühe, aber ich denke ich beende die Sache hier. Versuche es in weiteren 6 Jahren wieder. Offenbar sind diese VMs immer ganz speziell und werden wohl nie einwandfrei funktionieren.
Gruß Anreni
Dein letzter Satz verwirrt mich nun aber. Ich habe das CMD im Gast benutzt wie im Beitrag beschrieben. Das ist doch korrekt? VM ist gestartet und Gast ist gebootet.
embedded descriptor ?? Da muss ich mich dann wieder mit befassen. Au Backe, wird wohl wieder so ein Ding wie der log. ...Kann das denn nicht einfach mal funktionieren?
Habe jetzt bestimmt 6 Jahre VMware nicht mehr benutzt, weil ich eigentlich schneller ein System neu aufgesetzt habe wie es mit VMware in Ruhe zu konfigurieren. Und warum, weil diese ganzen VM Geschichten nicht richtig funktionierten. Na nach dieser langer Zeit dachte ich die Sache wäre nun einfacher. Und was ist, es klappt hinten und vorne nicht. Was soll so ein Mist? Ein Trost bleibt die Mitstreiter sind noch übler.
Langsam hab ich die Nase voll. Danke an alle .. .und vor allem an Dayworker für deine Mühe, aber ich denke ich beende die Sache hier. Versuche es in weiteren 6 Jahren wieder. Offenbar sind diese VMs immer ganz speziell und werden wohl nie einwandfrei funktionieren.
Gruß Anreni
-
Dayworker
- King of the Hill
- Beiträge: 13656
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Ich finds echt schade, daß du jetzt schon aufgibst. VMs sind eigentlich nichts spezielles, wenn man ein paar Dinge beachtet und auch die Config human gestaltet.
Zu letzterem zählt beispielsweise, daß man nur soviel RAM, CPU und vDISK einstellt, wie unbedingt benötigt und nicht wie möglich ist. Das bedeutet in deinem Fall, also vor allem keine 100GB Sparse-Disk und beim RAM reichen selbst bei einem 64bit-Gast für gewöhnlich 2GB aus. Sparse-Disks sind zwar Platzsparender als dessen Preallocated-Pendant, belegen also nur real geschriebene Sektoren auf der Host-Platte. Sie fragmentieren aber auch schneller, da neue Sektoren vom Host-OS erst angefordert werden, wenn der Gast Daten zu schreiben hat. Dadurch verteilt sich eine VMDK dann über die gesamte Host-Platte und erschwert zusätzlich die Datenrettung im Ernstfall. Nicht vergessen darf man auch, daß es bei einer Sparse-Disk für den freien Platz auf dem Host-Datenträger gefährlich wird, wenn man entweder das Sparse-Laufwerk komplett- und nicht schnellformatiert oder die üblichen Defragmentierungsläufe startet. Beides bläst eine Sparse-Disk zuverlässig auf die spezifierte Grösse auf und das sind in deinem Fall mal eben 100GB. Wenn dem Gast/VM der Platz wegen Speichermangel auf dem Host-Datenträger ausgeht, stürzt entweder nur die VM oder auch das Host-OS ab und bei einem komplett vollgeschriebenen Startlaufwerk (C oder Root) starten weder Windows noch Linux nicht mehr.
In deinem Fall hättest du einfach die VMDK vom Host aus reparieren müssen und so hab ich es auch geschrieben. Weil wenn der Gast läuft, wie willst du da die äussere Struktur der Gast-Platte bearbeiten? VMware hat da eine Sicherheitssperre namens LCK-Dateien eingebaut, die beim Start einer VM erstellt werden.
Zu letzterem zählt beispielsweise, daß man nur soviel RAM, CPU und vDISK einstellt, wie unbedingt benötigt und nicht wie möglich ist. Das bedeutet in deinem Fall, also vor allem keine 100GB Sparse-Disk und beim RAM reichen selbst bei einem 64bit-Gast für gewöhnlich 2GB aus. Sparse-Disks sind zwar Platzsparender als dessen Preallocated-Pendant, belegen also nur real geschriebene Sektoren auf der Host-Platte. Sie fragmentieren aber auch schneller, da neue Sektoren vom Host-OS erst angefordert werden, wenn der Gast Daten zu schreiben hat. Dadurch verteilt sich eine VMDK dann über die gesamte Host-Platte und erschwert zusätzlich die Datenrettung im Ernstfall. Nicht vergessen darf man auch, daß es bei einer Sparse-Disk für den freien Platz auf dem Host-Datenträger gefährlich wird, wenn man entweder das Sparse-Laufwerk komplett- und nicht schnellformatiert oder die üblichen Defragmentierungsläufe startet. Beides bläst eine Sparse-Disk zuverlässig auf die spezifierte Grösse auf und das sind in deinem Fall mal eben 100GB. Wenn dem Gast/VM der Platz wegen Speichermangel auf dem Host-Datenträger ausgeht, stürzt entweder nur die VM oder auch das Host-OS ab und bei einem komplett vollgeschriebenen Startlaufwerk (C oder Root) starten weder Windows noch Linux nicht mehr.
In deinem Fall hättest du einfach die VMDK vom Host aus reparieren müssen und so hab ich es auch geschrieben. Weil wenn der Gast läuft, wie willst du da die äussere Struktur der Gast-Platte bearbeiten? VMware hat da eine Sicherheitssperre namens LCK-Dateien eingebaut, die beim Start einer VM erstellt werden.
Tja, wenn aber alles bockt, was soll da noch Laune machen.
Es gibt ja Gott weiß mehrere CMD Eingabemöglichkeiten im System. Denkst du ich habe nicht alle versucht? Bei geschlossenem VMware, ebenso wie geöffnetem .. im CMD physikalisches System wie im CMD Host oder Gast. Es geht nicht! Wenn natürlich der vdiskmanager defekt ist kann es ja nicht gehen, doch da alle Seiten wieder mal nur in Englisch gefasst sind ist mir das Ding wirklich langsam zu mühsam.
In dem zum Thema verlinkten Seite wird die Reparatur aber vom gestarteten Gast ausgeführt. Daher war eigentlich klar, dass es dieses sein muss. Und jetzt war das falsch?
Ich mache jetzt noch ein paar Tests und dann lösche ich das Teil vom System.
Die Option mit der varialblen Disk Größe fand ich eigentlich praktisch. Das dies diese Problem aufwirft war mit nicht bewusst. Habe vorher schon ein System eingerichtet mit 20GB doch die war eben zu klein und gleich am Ende. Also nochmals und dort stellte ich dann diese Option ein. Das Problem mit den "vergessenen DVD Laufwerken" war aber bei allen bislang erstellten Gast Systemen , drei an der Zahl. Ich kann mir deshalb nur vorstellen, dass der Fehler bei VMware liegt und nicht in einem fehlerhaften Gast System. Eine Reparatur würde daher wohl auch nichts bringen. Installiert wurden auch unterschiedliche W7 Versionen. Daran kann es dann ja auch nicht liegen.
Auch regt mich auf, dass viele der verlinkten Seiten nicht in deutsch vorhanden sind und die Fachbegriffe auch nicht übersetzbar sind, und auch nicht so ohne weiteres Selbsterklärend sind. Bin kein Informatiker, lediglich ein User der gerne ausprobiert und neues versucht.
Gruß
Anreni
Es gibt ja Gott weiß mehrere CMD Eingabemöglichkeiten im System. Denkst du ich habe nicht alle versucht? Bei geschlossenem VMware, ebenso wie geöffnetem .. im CMD physikalisches System wie im CMD Host oder Gast. Es geht nicht! Wenn natürlich der vdiskmanager defekt ist kann es ja nicht gehen, doch da alle Seiten wieder mal nur in Englisch gefasst sind ist mir das Ding wirklich langsam zu mühsam.
In dem zum Thema verlinkten Seite wird die Reparatur aber vom gestarteten Gast ausgeführt. Daher war eigentlich klar, dass es dieses sein muss. Und jetzt war das falsch?
Ich mache jetzt noch ein paar Tests und dann lösche ich das Teil vom System.
Die Option mit der varialblen Disk Größe fand ich eigentlich praktisch. Das dies diese Problem aufwirft war mit nicht bewusst. Habe vorher schon ein System eingerichtet mit 20GB doch die war eben zu klein und gleich am Ende. Also nochmals und dort stellte ich dann diese Option ein. Das Problem mit den "vergessenen DVD Laufwerken" war aber bei allen bislang erstellten Gast Systemen , drei an der Zahl. Ich kann mir deshalb nur vorstellen, dass der Fehler bei VMware liegt und nicht in einem fehlerhaften Gast System. Eine Reparatur würde daher wohl auch nichts bringen. Installiert wurden auch unterschiedliche W7 Versionen. Daran kann es dann ja auch nicht liegen.
Auch regt mich auf, dass viele der verlinkten Seiten nicht in deutsch vorhanden sind und die Fachbegriffe auch nicht übersetzbar sind, und auch nicht so ohne weiteres Selbsterklärend sind. Bin kein Informatiker, lediglich ein User der gerne ausprobiert und neues versucht.
Gruß
Anreni
-
Dayworker
- King of the Hill
- Beiträge: 13656
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Also den "vmware-vdiskmanager" mußt du immer auf dem Host, sprich Rechner worauf das jeweilige VMware-Desktopprodukt installiert wurde, ausführen. Das der "vdiskmanager" defekt ist, war mir nicht bekannt.
Das alle möglichen Seiten und auch die WS in Englisch sind, ist wirklich ein Glück. VMware hat selbst bei seinem Profiprodukt ESXi nur eine sinnentstellende 1:1-Übersetzung fertig gebracht und mit diesem Machwerk kann man dann nicht mal im Web suchen. Die manuelle Rückübersetzung über einen Webdienst wie Babelfish & Co ergibt in einem solchen Fall nur noch mehr Blödsinn.
Du mußt bei allen ein VMware-Produkt betreffende Sachen immer zwischen Host sprich PC/Notebook und Gast sprich VM unterscheiden. Während für den Gast sein Datenträger eine normale Festplatte mit IDE-, SCSI- oder SAS-Anschluß ist, sieht das Host-OS an dieser Stelle nur eine oder mehrere Dateien mit der Dateiendung VMDK und weiß von Inhalt oder Aufbau überhaupt nichts. Lediglich der "vdiskmanager" ist in der Lage, die innere Datenstruktur zu "sehen" und notfalls zu reparieren.
Wegen der vDISK mit 20GB kann ich dir nur empfehlen, daß Gast-OS mit Programmen darin zu installieren und für die Benutzerdaten eine weitere vDISK mit mehr Platz zu erstellen. Seit Vista hilft M$ ja auch aktiv beim Umzug der Benutzerdaten auf eine andere Partition oder Datenträger mit und führt eventuell notwendige Registry-Einträge eigenständig nach. Dazu war unter XP beispielsweise noch der manuelle Eingriff in die Registry von Nöten.
Die "vergessenen DVD Laufwerken" sind auch ein Thema für sich. Erklären könnte ich die mir nur, wenn man die Easy-Installation von VMware nach Anlegen einer neuen VM übernimmt. Sobald man eine VM neu angelegt hat, fragt die WS/Player nach, ob man die Inst jetzt oder später machen will. Die im nachhinein richtige Antwort an dieser Stelle lautet SPÄTER, auch wenn man das Gast-OS gleich installieren will. Falls man dagegen JETZT ausgewählt hat, erstellt VMware auf Basis des Gast-Inst-Mediums und der vorgefundenen Sprachen eine Floppy-Disk für die unbeaufsichtigte/unattended OS-Installation. Bei dieser werden dann alle Rückfragen der Gast-OS-Inst direkt über die Antworten auf der Floppy ausgegeben. Der Vorteil dieser Inst-Methode ist, daß man über entsprechende Einträge auch den zu installierenden Programmumfang beeinflussen kann. Mann kann beispielsweise Spiele und sonstige später unnötige OS-Programme von der Liste streichen oder darüber auch die Netzwerk-Config samt Verhaltens für Win-Updates abwickeln. Nachteilig ist dabei, daß man zu Beginn von Win7 dann stellenweise nicht mal mehr die genaue Win7-Version angeben konnte, was extrem unglücklich ist, da bei Win7 gleich alle Versionen (Home, Business etc) in einer einzigen Inst-Datei stecken. Bei Win8 dürfte es auch nicht viel anders sein.
Das alle möglichen Seiten und auch die WS in Englisch sind, ist wirklich ein Glück. VMware hat selbst bei seinem Profiprodukt ESXi nur eine sinnentstellende 1:1-Übersetzung fertig gebracht und mit diesem Machwerk kann man dann nicht mal im Web suchen. Die manuelle Rückübersetzung über einen Webdienst wie Babelfish & Co ergibt in einem solchen Fall nur noch mehr Blödsinn.
Du mußt bei allen ein VMware-Produkt betreffende Sachen immer zwischen Host sprich PC/Notebook und Gast sprich VM unterscheiden. Während für den Gast sein Datenträger eine normale Festplatte mit IDE-, SCSI- oder SAS-Anschluß ist, sieht das Host-OS an dieser Stelle nur eine oder mehrere Dateien mit der Dateiendung VMDK und weiß von Inhalt oder Aufbau überhaupt nichts. Lediglich der "vdiskmanager" ist in der Lage, die innere Datenstruktur zu "sehen" und notfalls zu reparieren.
Wegen der vDISK mit 20GB kann ich dir nur empfehlen, daß Gast-OS mit Programmen darin zu installieren und für die Benutzerdaten eine weitere vDISK mit mehr Platz zu erstellen. Seit Vista hilft M$ ja auch aktiv beim Umzug der Benutzerdaten auf eine andere Partition oder Datenträger mit und führt eventuell notwendige Registry-Einträge eigenständig nach. Dazu war unter XP beispielsweise noch der manuelle Eingriff in die Registry von Nöten.
Die "vergessenen DVD Laufwerken" sind auch ein Thema für sich. Erklären könnte ich die mir nur, wenn man die Easy-Installation von VMware nach Anlegen einer neuen VM übernimmt. Sobald man eine VM neu angelegt hat, fragt die WS/Player nach, ob man die Inst jetzt oder später machen will. Die im nachhinein richtige Antwort an dieser Stelle lautet SPÄTER, auch wenn man das Gast-OS gleich installieren will. Falls man dagegen JETZT ausgewählt hat, erstellt VMware auf Basis des Gast-Inst-Mediums und der vorgefundenen Sprachen eine Floppy-Disk für die unbeaufsichtigte/unattended OS-Installation. Bei dieser werden dann alle Rückfragen der Gast-OS-Inst direkt über die Antworten auf der Floppy ausgegeben. Der Vorteil dieser Inst-Methode ist, daß man über entsprechende Einträge auch den zu installierenden Programmumfang beeinflussen kann. Mann kann beispielsweise Spiele und sonstige später unnötige OS-Programme von der Liste streichen oder darüber auch die Netzwerk-Config samt Verhaltens für Win-Updates abwickeln. Nachteilig ist dabei, daß man zu Beginn von Win7 dann stellenweise nicht mal mehr die genaue Win7-Version angeben konnte, was extrem unglücklich ist, da bei Win7 gleich alle Versionen (Home, Business etc) in einer einzigen Inst-Datei stecken. Bei Win8 dürfte es auch nicht viel anders sein.
Dayworker hat geschrieben:Die "vergessenen DVD Laufwerken" sind auch ein Thema für sich. Erklären könnte ich die mir nur, wenn man die Easy-Installation von VMware nach Anlegen einer neuen VM übernimmt. Sobald man eine VM neu angelegt hat, fragt die WS/Player nach, ob man die Inst jetzt oder später machen will. Die im nachhinein richtige Antwort an dieser Stelle lautet SPÄTER, auch wenn man das Gast-OS gleich installieren will. Falls man dagegen JETZT ausgewählt hat, erstellt VMware auf Basis des Gast-Inst-Mediums und der vorgefundenen Sprachen eine Floppy-Disk für die unbeaufsichtigte/unattended OS-Installation. Bei dieser werden dann alle Rückfragen der Gast-OS-Inst direkt über die Antworten auf der Floppy ausgegeben. Der Vorteil dieser Inst-Methode ist, daß man über entsprechende Einträge auch den zu installierenden Programmumfang beeinflussen kann. Mann kann beispielsweise Spiele und sonstige später unnötige OS-Programme von der Liste streichen oder darüber auch die Netzwerk-Config samt Verhaltens für Win-Updates abwickeln. Nachteilig ist dabei, daß man zu Beginn von Win7 dann stellenweise nicht mal mehr die genaue Win7-Version angeben konnte, was extrem unglücklich ist, da bei Win7 gleich alle Versionen (Home, Business etc) in einer einzigen Inst-Datei stecken. Bei Win8 dürfte es auch nicht viel anders sein.
Genau das könnte mein Fehler gewesen sein. Hab immer "Ja" gesagt und die Automatic alles erledigen lassen.
Versuch die Daten per vdk.exe auszulesen, oder auch mit WinImage
Welche Datei soll ich auslesen continuum? Und wer findet dort was und was fang ich damit an? Bringt die mich weiter oder zeigt die nur, dass der vdiskmanager defekt ist?
Alles doch nur Flickschusterei oder?
Fehlt eben eine ordentliche Anleitung bei der Installation wie ich hier lese, damit man solche Fehler vermeidet und keinen Frust hat.
Kommt Leute, alles gut gemeint, aber die VM scheint bei mir verbockt zu sein. Ich teste noch ein paar Programme mit meinem Gastsystem und dann ist Schluss damit. Dachte ich könnte mir ein W7 rundum zusammenbasteln für die nächste frische Installation, diese per Acronis sichern und dann später bei Bedarf recovern. So einen Hype wollte ich nicht veranstalten. Ist doch nur ein Hobby und Freizeitvergnügen. Soll ja nicht frusten.
Werde aber sicherlich bei dem nächsten Versuch an euch denken und einiges mehr beachten.
Gruß
Anreni
-
continuum
- UNSTERBLICH(R.I.P.)
- Beiträge: 14759
- Registriert: 09.08.2003, 05:41
- Wohnort: sauerland
- Kontaktdaten:
Dayworker hat geschrieben:@Ulli
Reicht es eigentlich nicht aus, wenn er einfach den längeren Weg geht und die VMDK in eine Preallocated umwandelt oder geht das etwa auch nicht
wenn die graintables in der sparse vmdk defekt sind kann er erst gar nicht in preallocated convertieren.
Es ist echt ein absoluter Witz dass VMware damit durch kommt, kein funktionierendes Tool zum Fixen von sparse vmdks anzubieten.
-
Dayworker
- King of the Hill
- Beiträge: 13656
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Ulli spricht von der VMDK-Datei, die er per "vdk.exe" oder "WinImage" auslesen würde.
Könnte man auch machen und dann eine neue VMDK-Datei in der WS-Anwendung anlegen sowie den Inhalt der alten VMDK wieder zurückspielen.
Da sich die HW in einer VM von den tatsächlichen Gegebenheiten heutiger HW sehr unterscheidet, beispielsweise hat kein MB heute noch einen BX440-Chipsatz vom Pentium3 und IDE oder SCSI hat auch kaum ein Desktop-Rechner, wirst du mit dem Ausrollen einer VM auf Echtblech eh nicht weit kommen. Du mußt zumindest in der Registry noch manuell das Laden aller Plattencontrollertypen reaktivieren.
Könnte man auch machen und dann eine neue VMDK-Datei in der WS-Anwendung anlegen sowie den Inhalt der alten VMDK wieder zurückspielen.
Da sich die HW in einer VM von den tatsächlichen Gegebenheiten heutiger HW sehr unterscheidet, beispielsweise hat kein MB heute noch einen BX440-Chipsatz vom Pentium3 und IDE oder SCSI hat auch kaum ein Desktop-Rechner, wirst du mit dem Ausrollen einer VM auf Echtblech eh nicht weit kommen. Du mußt zumindest in der Registry noch manuell das Laden aller Plattencontrollertypen reaktivieren.
O.k. Jungs... mit WinImage konnte ich die vmdk öffnen. Was nun? Mit der vdk.exe war ja gar nichts anzufangen. Die tat gar nichts. Kurzes aufpopen eines CMD Fensters..das war es dann.
Mit WinImage könnte ich diese dann Exportieren. Was dann?
Wie könnte ich jetzt eine neue vmdk erstellen? Oder verändern? Die geöffnete vmdk sieht aus wie eine übliche C Partition. Wäre also möglich dort alles zu verändern und dann wieder zu schließen oder?
Hab schon versucht auf IDE und legancy umzustellen. Nee brachte leider nichts. War eigentlich das erste was ich hier im Forum fand als Tipp und mich dann zu euch verschlug.
Ja wird wohl so stimmen, doch mit der Acronis PlusPack Version kann man beim recovern die benötigten Treiber manuell nachschieben. Verändert denn die VMware das Image des W7 so stark, dass solche Grundfunktionen wie der Plattencontroller einfach abgestellt werden? Wow , das hätte ich jetzt nicht gedacht.
Mit WinImage könnte ich diese dann Exportieren. Was dann?
Wie könnte ich jetzt eine neue vmdk erstellen? Oder verändern? Die geöffnete vmdk sieht aus wie eine übliche C Partition. Wäre also möglich dort alles zu verändern und dann wieder zu schließen oder?
Hab schon versucht auf IDE und legancy umzustellen. Nee brachte leider nichts. War eigentlich das erste was ich hier im Forum fand als Tipp und mich dann zu euch verschlug.
Da sich die HW in einer VM von den tatsächlichen Gegebenheiten heutiger HW sehr unterscheidet, beispielsweise hat kein MB heute noch einen BX440-Chipsatz vom Pentium3 und IDE oder SCSI hat auch kaum ein Desktop-Rechner, wirst du mit dem Ausrollen einer VM auf Echtblech eh nicht weit kommen. Du mußt zumindest in der Registry noch manuell das Laden aller Plattencontrollertypen reaktivieren.
Ja wird wohl so stimmen, doch mit der Acronis PlusPack Version kann man beim recovern die benötigten Treiber manuell nachschieben. Verändert denn die VMware das Image des W7 so stark, dass solche Grundfunktionen wie der Plattencontroller einfach abgestellt werden? Wow , das hätte ich jetzt nicht gedacht.
Denke nun hat sich alles erledigt. Hab das WinImage geschlossen um die VM wieder zu starten, doch noch bevor das Gastsystem booten kann kommt:
Unable to open kernel device "\\.\Global\vmx86":Das System kann die angegebene Datei nicht finden. Did you reboot after installing VMware Worstation?
Failed to initialize Monitor device.
!! Die vmx86 ist noch vorhanden im VMware Programmverzeichnis. !!
Ich hab mit dem WinImage definitv nix verändert nur geschaut und geöffnet.
Anreni
Unable to open kernel device "\\.\Global\vmx86":Das System kann die angegebene Datei nicht finden. Did you reboot after installing VMware Worstation?
Failed to initialize Monitor device.
!! Die vmx86 ist noch vorhanden im VMware Programmverzeichnis. !!
Ich hab mit dem WinImage definitv nix verändert nur geschaut und geöffnet.
Anreni
O.k. , wie soll ich weiter vorgehen? Ich habe zwei VM in einer 100Gb Part. liegen und diese beiden booten nun nicht mehr. Eben mit dieser Fehlermeldung. Beide löschen und eine neu installieren, dann das Image mit WinImage zurückspielen?
Fahre morgen in Kurzurlaub... daher hab ich noch einiges zu erledigen. Mal sehen wann ich dazu komme.
Gruß
Anreni
Fahre morgen in Kurzurlaub... daher hab ich noch einiges zu erledigen. Mal sehen wann ich dazu komme.
Gruß
Anreni
Anreni hat geschrieben:..selbst das schreiben einer PN ist unter dieser Forumsstruktur ein Erlebnis. So umständlich habe ich es noch in keinem Forum erlebt. Gibt Zeit für ein Update!
Mir gefällt das Altbackene Forendesign. Schnell, auf das wesentliche beschränkt und kein BlingBling.
Ist doch super easy ne Private Nachricht zu senden. PN andrücken unter einem Post des Benutzers.
Zurück zu „VMware Workstation und VMware Workstation Pro“
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 40 Gäste