VMware-Forum

Hallo Forum,

falls ich Netzwerkkarten frei habe (MgtNetwork, iSCSI natürlich getrennt davon) gebe ich dem vSwitch (VMNetwork), ausser einem Standby Adapter, immer alle noch verbleibenden Netzwerkkarten.
Mir ist aufgefallen, dass daraufhin die Windows Anmeldung (z.B. Terminalserver) wesentlich länger dauert. Beim Betrieb scheint das Netzwerk performanter mit mehr Netzwerkkarten; nur die Windowsanmeldung ist langsamer.
Gibt es dafür eine Erklärung? Stellt ich irgendetwas falsch ein? (Lastausgleich: Anhand der ursprünglichen ID des virtuellen Ports routen)

Danke.
ckoderer

Wie ist der Switch konfiguriert?
http://kb.vmware.com/selfservice/micros ... Id=1004048

Warum sollte man fuer das VM Network denn bitte schoen StandBy Adapter definieren und nicht alle Aktiv machen?

Also das etwas laenger dauern soll wenn man mehre pNICs am vSS bzw. PG hat ist mir noch nie aufgefallen und lese ich auch zum ersten male.

Gruss
Joerg

Wenn ich alle bis auf eine NIC im vSwitch deaktiviere , ist die Windows Anmeldung wieder "normal". Bin mir nicht sicher ob die URL mir eine Lösung bringt ....

Wenn du sie Standard-Policy ("Route based on virtual Port-ID"), wie oben erwähnt fährst, dann wird jeder VM eine (allerdings beliebige) vmnic der verfügbaren fest für die Laufzeit stabil zugewiesen, bis ein Ereignis (Ausfall, Aus- und wieder Einschalten mit neuen VMs, vMotion) eine Neuzuteilung erforderlich macht.

Hast du nur eine vmnic am vSwitch, wird allen VMs auch eine, aber genau die eine vmnic zugewiesen.

Aus Sicht der VM sollte das Verhalten also gleich sein. Ist es aber nicht. Laufen auf dem vSwitch noch andere VMs - und wenn ja, was für welche?

An diesem Switch sind z.B. verbunden DC Domänencontroller (=AnmeldeServer) und Terminalsserver und ein kommunikation-server für die Datev (eine Win8 Workstation) . Hab noch gar nicht getestet ob eine Anmedlung mit einem physischen Client auch so lange dauert, gehe davon aber aus.
Es siehr primär nicht so aus das die Anmeldung lange braucht um physisch Daten zu ziehen (große Benutzerprofil-Daten) sondern eher das der Client auf eine Antwort vom DC wartet (Authentifizierung, Kerberos-Ticket ...).

Teste das bitte trotzdem mit einem physischen Client - jede Information ist wichtig.

Du hast praktisch folgende Situation:

Im Fall einer physischen Karte sind alle virtuellen NICs aller VMs auf die eine physische Karte "gemappt". Sie kommen am physischen Switch alle an einem Port an.

Im Fall mehrerer vmnics (ich gehe davon aus, dass alle Karten am pSwitch angeschlossen sind) bekommen die VMs (eigentlich die vNICs) verschiedene physische Karten zugewiesen (nach Startreihenfolge) und kommen am pSwitch an verschiedenen Ports an.

Für die Inter-VM-Kommunikation sollte das eigentlich keinen Unterschied machen - von daher noch mal die Nachfrage: Ist auf den drei VMs selbst Virtualisierung aktiv oder betreibt eine der VMs die vNIC in einer Bridge?

zweite Nachfrage: Warum erwähnst du im Titel "Lastausgleich: IP-Hash"?

Kann leider kein Bild/PDF hochladen.

Der Titel ist falsch; es geht per default um "Anhand der ursprünglichen ID des virtuellen Ports routen". Das ist wohl Standard wenn man einem Standard-Switch mehrer Netzwerkkarten hinzufügt.

Es sind mehrere physikalische Nics. Nein keiner der VMs hat einen hypervisor.

Scheinbar haben die lokalen, physischen Client auch das "lange Anmelde-Problem"; also eher weniger Interne-VMWare-Kommunikation. Eher Probleme mit der Windows Anmeldung Domänencontroller.

Wenn dein pSwitch managebar sein sollte, schau mal in die MAC-Tabelle der betroffenen ESXi-Uplink-Ports, ob da alles korrekt zugeordnet wurde.

Das unser Forum keine Dateianhänge mehr erlaubt, steht mittlererweile in fast jedem Thread und in vielen User-Signaturen. Unsere Foren-SW blendet jedoch den Upload-Button leider trotzdem nicht aus und das führt häufiger zu Irritationen.
Daher gibt es hier immer den Rat, auf einen Freehoster oder eigenen Webspace zu verlinken.

Danke für den Hinweis.

Anbei das versprochene Bild ^^



Laut vmware kb ist es für diese Art der "Lastverteilung" nicht nötig den Switch zu konfigurieren.

Habt ihr noch eine andere Idee woran es liegen könnte?

Danke

P.S. das mit den 2 Standby Adapter war nur ein Versuch...

ckoderer hat geschrieben:Laut vmware kb ist es für diese Art der "Lastverteilung" nicht nötig den Switch zu konfigurieren.

Eigentlich nicht, das stimmt. Aber was ist, wenn doch jemand einen PortChannel konfiguriert hat?

Insofern ist ~thc's berechtigte Frage nach Type und ggfs. Konfiguration des physischen Switches in meinen Augen noch immer unbeantwortet.

Nein daran glaub ich nicht da ich bei einem anderem Kunden das gleiche Thema habe; und dort ist ein nagelneuer unkonfigueriert HP Switch eingebaut. Bei weiteren Kunden mit "mehr-als-einer-Netzwerk-Karte" am vSwitch hab ich die Windows Anmeldeverzögerung nicht. Da sind aber auch andere ESXi Hardware verbaut. Daran wird's wohl nicht liegen.

Wenn du mit mehreren Uplinks arbeitest und VMs vom ESXi von einer vmnic auf eine andere vmnic verschoben werden, muss das der pSwitch natürlich mitmachen. Sollte die MAC-Tabelle des pSwitch noch veraltete Einträge enthalten, wird das ungemütlich.

Was du noch probieren kannst:

- Mit Portgroups arbeiten und bei diesen vmnics bevorzugt zuweisen
- Tests mit zusätzlichen vSwitches, die die VMs isolieren.

OK. Vielen Dank für die vielen Anregungen. Ich werd's mal in meiner VMWare Testumgebung nachbauen und solange bekommt halt das VMNetwork nur eine pNIC.

Aber nur mal prinzipiell (zum Thema "hab ich den von der Konfig irgendeinen Performance-Schub")

DC01---------- vSwitch------ Nic1
RDS01--------..................... Nic2
komm-srv-1--..................... Nic3

Annahme: Die erste RemoteDesktop-Session zum RDS bekommt z.B. Nic1. Dann geht es wie beim RR Verfahren (z.B. DNS) weiter mit:
Zweite Session Nic2
Dritte Session Nic3
Vierte Session Nic1 ...

oder lieg ich da falsch?

Ja - so wäre das bei einem pSwitch-Trunk mit ESXi-"IP Hash"-Loadbalancing.

Beim Standard-Verfahren (Port ID) bekommt eine VM zur Laufzeit eine vmnic fest zugewiesen - bis sie abgeschaltet wird oder z. B. durch einen Hardwareausfall eine Neuzuweisung erzwungen wird.