VMware-Forum

Hi,

ich habe heute versucht eine "spezielle" VM, die ich mit VMware WS 7 angelegt habe, in VMware Server 2 zu registrieren. Die VM ist insofern "speziell", als dass sie nicht zu den supportet Guest-OS's zählt (OSX). Ich hatte dies schon einmal vor längerer Zeit probiert - damals wie heute mit dem gleichen Resultat: in der VMWare (Web-)Management-Console "hängt" der Task mit "registering vm", steht auf 0% und bleibt da. Das letzte Mal hatte ich den Rechner neu gestartet - ich frage mich nur gerade ob es nicht noch einen besseren Weg gibt. Auf der Suche im Web bin ich auf ein Script für den ESX gestoßen, das genau dieses Problem beheben soll. Die darin verwendeten Tools habe ich aber beim VMware-Server nicht gefunden. Kann mir da jemand weiter helfen?

Beste Grüße,

Das OSX auf VMserver 2 nicht laeuft ist normal - am besten fragst du die Leute von denen du die spezielle VM "bekommen" hast

Danke für die Antwort. Mir ging es aber weniger darum wie und ob ich die VM zum laufen bekomme, sondern vielmehr wie ich den Task "register vm" stoppen kann, der sich offensichtlich aufgehängt hat.

Um offen zu sein, die VM habe ich selbst erstellt. Ich habe mir im Mediamarkt die 10.6.3 SL für unter 30€ gekauft und damit ein wenig "gespielt". Es handelt sich also nicht um eine illegale Kopie o.Ä.. Diskussionen zur Rechtmäßigkeit einer solchen Installation gibt es genügend am Web, ich halte mich in diesem einen Fall an unseren Staat, der sagt dass die Informationen zur Lizens außen auf der Verpackung aufgedruckt sein müssen, ansonsten sind sie unwirksam. Wie soll ich auch vor dem Kauf wissen, dass ich es nur auf Apple-HW installieren darf, wenn der Hinweis dazu in der Verpackung liegt? Das nur so nebenbei. Unter VMWS7 läuft das Teil übrigens hervorragend.

Aber zurück zum Thema, wie - wenn überhaupt - kann man so einen Task "killen" ?

auf WS 7 laeuft es ?
Dann hast du evtl mit einem Bug des VMserver2 zu tuen den man durch einen Austausch des virtuellen BIOS beheben kann - ich such dir den link mal raus.

http://communities.vmware.com/thread/295103

Kannst du nicht den vmware-vmx.exe Prozess killen ?

Danke für die Antwort - aber wie schon gesagt, es geht nicht darum ob oder wie die VM läuft. Es geht darum den Task "register vm" zu killen. In diesem Stadium läuft auch noch kein dafür dedizierter vmware-vmx.exe Prozess - da die VM ja noch gar nicht gestartet wurde. Es geht allein um die Registrierung, die hängt und blockiert zudem auch noch das kpl. Web-Frontend.

Der VMserver2 spricht zwar dieselbe v.HW-Version wie die WS7, ansonsten haben sie aber seit der WS6.5.2 nichts mehr gemeinsam. Einige Parameter sind daher nicht lauffähig oder haben hier eine andere Wirkung und die VMX wird auch auf Plausibilität überprüft.
Deine Versuche sind also in meinen Augen mehr als sinnlos.

Vielen Dank für die Tipps - noch einmal: die Frage war NICHT wie ich die VM zum Laufen bekomme - das ist im Moment mehr als sekundär. Die Frage war, wie man einen Task (bitte nicht wieder mit VM verwechseln) killt.

kill den hostd

Yepp, das habe ich nach dem Neustart des "Servers" auch herausgefunden. Ich muss ehrlich gestehen, entgegen meiner bisherigen Überzeugung ist doch einiges wirklich Überraschendes, Beeindruckendes an Win7: z.B. der "Reliability Monitor". Der zeigt einem jedes "hüsteln" des Rechners. So auch bei dem "hanging task". Im (o.g.) Log findet sich ein Eintrag ala "Pfad der fehlerhaften Anwendung: C:\VMwareServer\vmware-hostd.exe", der entsprechende Service war schnell ausgemacht

Vielen Dank für Eure Mithilfe!

@continuum & OT:

Ich habe gerade mit großem Interesse Dein VMDK-Handb. "überflogen". Eine Frage: wie hoch würdest Du, evtl. auch nur als "Bauchgefühl", den Performance-Unterschied zwischen Sparse und Flat einordnen?

Eine Frage: wie hoch würdest Du, evtl. auch nur als "Bauchgefühl", den Performance-Unterschied zwischen Sparse und Flat einordnen?

ganz grob jetzt mal ...

100 % = schreibgeschwindigkeit des Hosts
85 % = gut defragmentierte SPARSE mit 100 % statischem Inhalt
80 % = gut defragentierte preallocated
60 % = gut gewartete sparse mit writes and reads = normale Nutzung
...
5 % = schlecht gewartete vmdk mit vielen grossen snapshots
0 % = schlecht gewartete vmdk mit vielen grossen snapshots nach Kollaps


so in etwa - bei sparse vmdks haengt die performance stark von der art der Nutzung ab:

bei hauptsaechlich statischem Inhalt = nur lesen - sind sparse vmdks ideal

je mehr geschrieben wird umso besser werden die preallocated