ich hab jetzt nochmal einen neuen thread aufgemacht, weil ich an einer Großbaustelle tüftle und ständig neue unklarheiten auftauchen.
Damit einfacher verständlich, hier eine Abbildung:
Am vmserver bildet vmnet1 die ip-addr 192.168.1.1 ab, die clients 1.55 bzw. 1.60. Mit ping erreichen sich 1.55 und 1.60 in beide Richtungen. Für beide ist 1.1 unerreichbar, auch kann der wirt nicht auf 1.55 bzw. 1.60 pingen.
Ich denke, 1.55 bzw. 1.60. sollten 1.1 antworten, ebenso umgekehrt.
Habe ich etwas grundlegendes übersehen oder falsch verstanden? oder müsste das in der dargestellten form funktionieren?
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!
HostOnly Verbindungsproblem
dann dürfte mein problem daran liegen, dass vmnet1 (ebenso wie vmnet0 und vmnet8) keine verbidung aufbauen bzw. zulassen.
ev. kann mir jmd einen tipp/hinweis liefern, wie ich diesen zustand behebe. Es trat übrigens nach einem update von debian 5 auf 6 auf. der vserver2 wurde bei der installation gepatcht - daran sollte es wohl kaum liegen.
ev. kann mir jmd einen tipp/hinweis liefern, wie ich diesen zustand behebe. Es trat übrigens nach einem update von debian 5 auf 6 auf. der vserver2 wurde bei der installation gepatcht - daran sollte es wohl kaum liegen.
Also ich habe nach dem Update auf Debian 6.0 die Funktionalität von zwei produktiven VMs vollständig verloren, da die Quellcode-Dateien für die diversen Interfaces (VMCI, VMXNET ext.) vom VMWare Server 2.0.2 mit der neuen Umgebung nicht mehr zurecht kamen.
Nach einem Beinahe-Herzanfall habe ich diesen Patch
http://www.troublenow.org/316/installin ... 6-0-1-x64/
gefunden und damit die VMs gerettet. Das war damals übrigens auch der Zeitpunkt, an dem ich vom EOL der Servers erfuhr...
Nach einem Beinahe-Herzanfall habe ich diesen Patch
http://www.troublenow.org/316/installin ... 6-0-1-x64/
gefunden und damit die VMs gerettet. Das war damals übrigens auch der Zeitpunkt, an dem ich vom EOL der Servers erfuhr...
Meinen Herzanfall hab ich schon hinter mir
Danke - ich kenn den Patch - wenn auch von einer anderen site!
Hab ihn dennoch eingespielt und bin beim gleichen Ergebnis:
192.168.1.1 kann die clients im subnetz 192.168.1.x nicht erreichen und umgekehrt.
Ich werde morgen mal die vmclients wegsichern und die Maschine komplett neu aufsetzen - und hoffen.
Einer alternative wäre ich ja grundsätzlich aufgeschlossen, nur müssten die vmclients portiert werden (viel aufwand), die konfiguration erlernt werden (viel aufwand) und letzendlich weiß man nicht, ob man zufrieden sein wird.
Bei mir lief vserver seit ca. 3 Jahren ohne Probleme - eben bis zu dem Zeitpunkt, als ich vor lauter Übermut ein update durchgeführt habe
lg
Danke - ich kenn den Patch - wenn auch von einer anderen site!
Hab ihn dennoch eingespielt und bin beim gleichen Ergebnis:
192.168.1.1 kann die clients im subnetz 192.168.1.x nicht erreichen und umgekehrt.
Ich werde morgen mal die vmclients wegsichern und die Maschine komplett neu aufsetzen - und hoffen.
Einer alternative wäre ich ja grundsätzlich aufgeschlossen, nur müssten die vmclients portiert werden (viel aufwand), die konfiguration erlernt werden (viel aufwand) und letzendlich weiß man nicht, ob man zufrieden sein wird.
Bei mir lief vserver seit ca. 3 Jahren ohne Probleme - eben bis zu dem Zeitpunkt, als ich vor lauter Übermut ein update durchgeführt habe
lg
Möglicherweise hätte auch meine Installation dieses Verhalten gezeigt - die beiden VMs liefen im bridged-Modus und vmnet1 hatte ich nicht aktiviert. (Meinen Ping-Test habe ich im VMWare Server 2 für Windows gemacht.)
Wenn du die VMs im Server 2.0.2 erstellt hast (HW Version 7), kannst du sie ohne weiteres auf einen ESXi "umtopfen" - ging bei mir problemlos.
Wenn du die VMs im Server 2.0.2 erstellt hast (HW Version 7), kannst du sie ohne weiteres auf einen ESXi "umtopfen" - ging bei mir problemlos.
-
- King of the Hill
- Beiträge: 13561
- Registriert: 01.10.2008, 12:54
- Wohnort: laut USV-Log am Ende der Welt...
Das Problem mit der nicht anpingbaren IP X.Y.Z.1 hatten wir vor kurzem erst im WS- oder Player-Bereich und wenn ich das noch richtig in Erinnerung habe, ist hinten die "1" nur das Gateway selbst. Der Host lauscht dagegen immer hinten auf der "2".
Die v.HW-Version spielt fuer die Uebernahme auf einen ESX(i) keine Rolle. Lediglich das VMDK-Format muss diesem gelaeufig sein. Das kann man dann entweder mit dem "vmware-vdiskmanager" oder lokal auf dem ESX(i) convertieren. Ansonsten jagt man die VM einfach komplett durch den VMware-Converter und laesst die VM direkt auf den neuen Host beamen. Allerdings ist der Converter nicht der Schnellste und eigentlich auch zuviel Arbeit.
Die v.HW-Version spielt fuer die Uebernahme auf einen ESX(i) keine Rolle. Lediglich das VMDK-Format muss diesem gelaeufig sein. Das kann man dann entweder mit dem "vmware-vdiskmanager" oder lokal auf dem ESX(i) convertieren. Ansonsten jagt man die VM einfach komplett durch den VMware-Converter und laesst die VM direkt auf den neuen Host beamen. Allerdings ist der Converter nicht der Schnellste und eigentlich auch zuviel Arbeit.
Dayworker hat geschrieben:Das Problem mit der nicht anpingbaren IP X.Y.Z.1 hatten wir vor kurzem erst im WS- oder Player-Bereich und wenn ich das noch richtig in Erinnerung habe, ist hinten die "1" nur das Gateway selbst. Der Host lauscht dagegen immer hinten auf der "2".
Meinst du diesen Thread hier? Da geht es um VMNet8 (NAT).
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 24 Gäste