also ich habs beseitigt. es läuft. irgendwie kam er wohl damit nicht klar, dass sich die erste konsole im einen ip-bereich befand wie die zweite, die mit iscsi und vmkernel port auf dem zweiten vswitch ist. Und die erste Konsole war auf dem v0switch der auf dem phys nic saß der direkt in den management switch ging. Ich habe diese Console in ein anderes Netz bewegt , also jetzt is es so dass, ISCSI Console 2 sitzt im 128.* Netz mit dem ISCSI Storage in einem IP Bereich, Vmotion sitz im .10.* Netz und die erste Konsole die direkt auf den Management Switch geht sitzt im *168. Netz. Wo auch die Out-of-Band Steuerung des Storage ist.
Also er hat mir ständig eine Console ausgeschaltet. Und auf der Ersten Console war kein ISCSI möglicht, es war nicht möglich den ISCSI Storage zu pingen.
Weil er damit nicht klar kam dass die Erste konsole im selben IP-Bereich liegt wie die zweite. war aber physicalisch gesehen an einem switch. der nicht mit dem ISCSI Switch in keiner Weise Verbunden ist.
Nun laufen zwei Consolen, vorher lief immer nur eine oder die andere und ich habe ISCSI Storage Verbindung.
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!
Vmware Infrastructure 3 Aufbau einer Testumgebung
Nun werde ich mal meine Gedanken zu dem Problem äußern 
Es ist natürlch blöd gewesen wenn das gleiche Netz auf zwei vSwitches in der Routingtabelle aber halt auf zwei unterschiedlichen phys adaptern ist. Ich denke, das ist das problem denn den ESX Server mit seinen 4 Nics kann man als Router sehen.
Wenn z.B die Routing tabell so aussieht
vSwitch0 192.168.128.0 gateway vnic1 (nur Console 1 192.168.128.10) phys nic 1
vSwitch1 192.168.128.0 gateway vnic0 ,vnic 2 , vnic3 (iscsi, iscsi console 4 iscsi 192.168.128.11) phys nic0 nic 2 nic 3
Haben wir ja zwei gleiche netze auf verschiedenen vSwitches und zwei gleiche Gateways.
Warum soll er unter den NICs routen wenn ein Ping ankommt mit dem Ziel im 128.xy ankommt , sprich zu dem anderen Vswitch schicken ?
Und überhaupt alles was im selben Netz ist wird ja auch logischer Weise nicht geroutet, warum auch.
Er hat ja erstmal zwei phys verbindungen aber laut Routing tabelle so gesehen als ob sie am gleichen Switch sitzen. Sind sie aber nicht.
Ein Arp Request von der ersten Console (zum Beispiel um im "gleichen" die Console 2 und somit die Verbindung zum iscsi storage zu finden was in dem 128.0 sitzt) geht auf den vSwitch0, da er ja laut Routing in dem 128.0 sitzt) und er findet natürlich kein iscsi , da dieser Nic ist ja in keinster weise mit ISCSI verbunden er hängt ja auf einem kleinen Management Switch. Und der ARP Request geht auch dahin.
Und den Vswitch1 beachtet er erstmal gar nicht dabei, der ja mit dem ISCSI kommunizieren kann, und auf dem phys ISCSI switch hängt.
Warum etweder eine Console ging oder die andere ? Ich denke weil er die Reihenfolge der Gateway-Routen in der Routingtabelle geändert hat. Und so ging entweder eine zu pingen oder die andere, weil nur eine aktiv sein könnte , bzw. er hat nur eine Rückroute immer genommen, und zwar die "falsche". Und wenn die Antwort auf den Ping in die anderen Nics geht die phys am anderen switch sitzen, wissen wir ja was passiert , siet man schöne meldung "Zielhost nicht erreichbar".
Der Zielhost bekommt zwar ein Paket, aber wir bekommen es nicht , da das Paket den anderen Gateway (gateway interface) genommen hat. Dann kann auch in diesem moment nur eine Console funktionieren. Da die andere wegen des "falschen" Gateways nicht antworten kann.
Es ist natürlch blöd gewesen wenn das gleiche Netz auf zwei vSwitches in der Routingtabelle aber halt auf zwei unterschiedlichen phys adaptern ist. Ich denke, das ist das problem denn den ESX Server mit seinen 4 Nics kann man als Router sehen.
Wenn z.B die Routing tabell so aussieht
vSwitch0 192.168.128.0 gateway vnic1 (nur Console 1 192.168.128.10) phys nic 1
vSwitch1 192.168.128.0 gateway vnic0 ,vnic 2 , vnic3 (iscsi, iscsi console 4 iscsi 192.168.128.11) phys nic0 nic 2 nic 3
Haben wir ja zwei gleiche netze auf verschiedenen vSwitches und zwei gleiche Gateways.
Warum soll er unter den NICs routen wenn ein Ping ankommt mit dem Ziel im 128.xy ankommt , sprich zu dem anderen Vswitch schicken ?
Und überhaupt alles was im selben Netz ist wird ja auch logischer Weise nicht geroutet, warum auch.
Er hat ja erstmal zwei phys verbindungen aber laut Routing tabelle so gesehen als ob sie am gleichen Switch sitzen. Sind sie aber nicht.
Ein Arp Request von der ersten Console (zum Beispiel um im "gleichen" die Console 2 und somit die Verbindung zum iscsi storage zu finden was in dem 128.0 sitzt) geht auf den vSwitch0, da er ja laut Routing in dem 128.0 sitzt) und er findet natürlich kein iscsi , da dieser Nic ist ja in keinster weise mit ISCSI verbunden er hängt ja auf einem kleinen Management Switch. Und der ARP Request geht auch dahin.
Und den Vswitch1 beachtet er erstmal gar nicht dabei, der ja mit dem ISCSI kommunizieren kann, und auf dem phys ISCSI switch hängt.
Warum etweder eine Console ging oder die andere ? Ich denke weil er die Reihenfolge der Gateway-Routen in der Routingtabelle geändert hat. Und so ging entweder eine zu pingen oder die andere, weil nur eine aktiv sein könnte , bzw. er hat nur eine Rückroute immer genommen, und zwar die "falsche". Und wenn die Antwort auf den Ping in die anderen Nics geht die phys am anderen switch sitzen, wissen wir ja was passiert , siet man schöne meldung "Zielhost nicht erreichbar".
Der Zielhost bekommt zwar ein Paket, aber wir bekommen es nicht , da das Paket den anderen Gateway (gateway interface) genommen hat. Dann kann auch in diesem moment nur eine Console funktionieren. Da die andere wegen des "falschen" Gateways nicht antworten kann.
Hier ist die Lösung des Problems mit Pegasus, ansonsten gibts die Info dass es gefixt wird, in den nächsten updates.
http://www.yellow-bricks.com/2008/04/28/pegasus-error-after-installing-esx-35-update-1/
http://www.yellow-bricks.com/2008/04/28/pegasus-error-after-installing-esx-35-update-1/
Nun ja ich habe nicht gedacht, dass ich in das Thema so schnell reinkomme und mit der Testumgebung so schnell weiterkomme ohne "VCP" zu sein , aber es gibt genug Dokus, gute Bücher und natürlich diesen guten Forum , und wenn dann noch die Hardware mitspielt, Linuxkenntnisse sind auch nicht verkehrt .
Was einem dabei manchmal fehlt ist die Zeit, das ist ein Luxus den man nicht immer hat.
Natürlich ist die Testumgebung nur ein Fundament, ich werde den Rest des kostenlosen Testzeitraums (noch 50 Tage ) damit verbringen.
, aber es gibt genug Dokus, gute Bücher und natürlich diesen guten Forum , und wenn dann noch die Hardware mitspielt, Linuxkenntnisse sind auch nicht verkehrt .
Was einem dabei manchmal fehlt ist die Zeit, das ist ein Luxus den man nicht immer hat.
Natürlich ist die Testumgebung nur ein Fundament, ich werde den Rest des kostenlosen Testzeitraums (noch 50 Tage ) damit verbringen.
Wer ist online?
Mitglieder in diesem Forum: 0 Mitglieder und 8 Gäste