Virtual Center Problem. Dringend

[neo23]

Hallo Leute,

haben folgendes Problem beim Kunden:

Wenn wir uns ins VirtualCenter loggen und dann eine VM auswählen und auf "Console" klicken, ist der Bildschirm schwarz. (Error Connecting)

Über Remotedesktop bekommen wir eine einwandfreie Verbindung.

Der Kunde hat den ESX neu gestartet, danach war das Problem für eine Weile verschwunden.

Woran kann es liegen?

Diese Fehlermeldungen haben wir bekommen:

//
The description for Event ID ( 1000 ) in Source ( VMware VirtualCenter Server ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: Failed to intialize VMware VirtualCenter. Shutting down....

//
The VMware VirtualCenter Server service terminated unexpectedly. It has done this 75 time(s). The following corrective action will be taken in 300000 milliseconds: Restart the service.


Bitte helft mir.

[Heros]

Hört sich an als wäre die Installation des VC kaputt.

Du kannst das VC über Kommandozeile starten und mit lesen was alles passiert. Das hilft oft. Weiß leider die Option nicht auswendig. Schau dir das mal an und versuch es damit.

[neo23]

Kennt jemand den Befehl?

[ostekl1]

C:\Program Files\VMware\Infrastructure\VirtualCenter Server\vpxd.exe

ggf. mit --help oder /help oder /? versuchen

[Heros]

genau

[neo23]

Also VC lief schon die ganze Zeit, hab jetzt mal von der Kommandozeile aus gestartet:


C:\Documents and Settings\bgvmware>"C:\Program Files\VMware\VMware VirtualCenter
2.0\vpxd.exe" -r
[2008-02-18 15:53:03.051 'App' 3588 info] Current working directory: C:\Document
s and Settings\bgvmware
[2008-02-18 15:53:03.051 'App' 3588 info] Initializing SSL context
[2008-02-18 15:53:03.911 'App' 3588 info] Vmacore::InitSSL: doVersionCheck = tru
e, handshakeTimeoutUs = 120000000
[2008-02-18 15:53:03.926 'BaseLibs' 3588 info] NFC connection accept timeout: 18
0000 milliseconds

[2008-02-18 15:53:03.926 'BaseLibs' 3588 info] NFC request timeout: 180000 milli
seconds

[2008-02-18 15:53:03.926 'BaseLibs' 3588 info] NFC read timeout: 60000 milliseco
nds

[2008-02-18 15:53:03.926 'BaseLibs' 3588 info] NFC write timeout: 600000 millise
conds

[2008-02-18 15:53:03.926 'App' 3588 error] Service is already registered.
Service is already registered.

C:\Documents and Settings\bgvmware>


Bekomme teilweise auch Probleme wenn ich mir über den Infrastruktur Client ins VC logge und dann rechts eine VM auswähle und dann mir die Console anzeigen lassen will, dann erscheit folgende Meldung:

Error connecting: Cannot connect to host XXX. Ein Verbindungsfehler ist aufgetreten. Da die Gegenstelle nach einer bestimmten Zeit nicht geantwortet hat.

Kann halt nicht die Console nutzen, aber weiterhin Einstellungen am Host vornehmen über das VC

[inxs4u]

Der Rechner auf dem VC läuft muss den ESX Host via TCP/IP erreichen können. Prüfe doch mal ob Du den ESX Host via ping direkt erreichen kannst.
Meist sind das Managementnetz und das Produktivnetz nämlich nicht via Defaultrouting erreichbar.

[Tschoergez]

Ja, und auch der Rechner, auf dem der VI Client läuft, braucht Verbindung (und namensauflösung) zur Service Console.

Consolenverbdingungen gehen immer direkt vom VI Client zur Service Console vom ESX, wo die VM läuft! (auch wenn man am VC angemeldet ist)

Klappts denn beim WebAccess (auch da gehen die consolen-verbindungen direkt zum ESX)?

viele grüße,
jörg

[decom]

habe das gleiche problem .. siehe: http://vmware-forum.de/viewtopic.php?t=13742

[technicman]

Hallo,

hatte das Problem auch.
Aber man muß bei VMware wirklich "um die Ecke" denken.
Es reicht nicht, mit dem VI CLient im selben Subnetz zu sein. Die Namensauflösung ist viel entscheidender.
Anscheinend gehen die Entwickler bei VMware davon aus, dass man sich besser Namen als Zahlen merken kann

Bei mir hat's jedenfalls mit dem Client, der in der DNS Tabelle eingetragen war sofort funktioniert.

Gruß
Stephan

[decom]

es war tatsächlich später die namensauflösung... vorallem die "hosts"-dateien waren nicht sauber gepflegt und darin dürfen ja auch keine großbuchstaben enthalten sein auf sowas muss man erstmal kommen

danke an alle, die geholfen haben!!! (s.a. http://vmware-forum.de/viewtopic.php?p=60175... gleiches Problem)

[GTMK]

Es scheint, als ob mit U2 einige Verschärfungen wirksam geworden sind. So streikte danach bspw. meine HA. Erst nachdem in der Hosts-Datei auf Kleinschreibung geachtet wurde, FQDNs eingetragen wurden und den Hosts als Name der FQDN verpaßt wurde, lief sie wieder an. Mit der Original-3.5 lief die HA ohne diese Änderungen.

Es paßt zwar nicht in diesen Fred, aber dennoch in diesem Zusammenhang: Ich habe noch eine Reihe von vDisks, deren dbb.adapterType = "legacyESX" ist. Diese vDisks lassen sich seit U2 über das Virtual Center nicht mehr VMs als Platte hinzufügen. Mit dem VC-Client direkt auf den ESX oder ganz zu Fuß (per vi auf die .vmx) geht es... Lösung: Man muß den Eintrag in der .vmdk-Metadaten-Datei händisch auf "lsilogic" setzen. (Ooops)

Georg.

[Tschoergez]

ja, das sind lustige Effekte. Drum sollte man so ein Upgrade nicht gerade am Freitag nachmittag machen ("Gott sei Dank, Montag is Berufschule" )

VMware täte gut daran, solche Dinge auch irgendwo in die Release Notes zu schreiben (mir würde ja schon Kleingedrucktes reichen), nicht immmer nur die NEUEN features....

Aber mit der Zeit gewöhnt man sich dran, plant etwas mehr Zeit für den Upgrade ein, und wartet mit der Tüte Popcorn in der Hand gespannt darauf, was diesmal schiefgeht

Viele grüße,
Jörg