VMware-Forum

Hallo,

Wir haben unter SuSE Linux Enterprise Server 10/11 VMs seit der Einführung von ESXi 5.x Probleme bei vmotion.

Als wir noch 4.1 im Einsatz hatten, war das definitiv nicht so schlimm. (Stun max. 3-4Sek)
Es wirkt sich folgendermaßen aus:
Wenn große VMs (ca. 40GB RAM u. 4-6 vCores) unter Last verschoben werden müssen dauern diese Stuns beim Delta-Nachschreiben bis zu 40 Sekunden. Kaum eine Applikation überlebt das und diese Hänger sind bis zum Endkunden deutlich spürbar. Jobs brechen/stürzen ab usw.

Es ist mir klar, dass unter Last stehende Maschinen nicht ganz so einfach verschieb bar sind wie welche, die nur idlen. Allerdings ist dieses Verhalten bei Windows-VMs nicht nachstellbar. Habe sogar schon eine 64GB VM mit 8vCores mit Prime95 voll beschäftigt. dh. fast der komplette RAM im aktive Status und alle Cores zu 100% beschäftigt. Der vmotion Prozess dauert ziemlich lange (sicher an die 3-4 Minuten), dafür aber ohne spürbaren Stun beim endgültigen Verschieben.

Was ich bisher rausgefunden habe:
Seit der ESXi 5.x gibt es ja für vmotion dieses "Stun During Page Send" Feature (kurz: SDPS). Wenn ich dieses Feature in den Advance Parametern auf Hostbasis deaktivere verhält sich die Windows VM genau gleich bescheiden wie die Linuxen. Sprich 40 Sekunden Stun und kein Ping möglich in dieser Zeit.
Schalte ich das feature wieder an ist unter Windows kein Stun festzustellen und unter Linux ists schlecht wie immer.
Kann das sein, dass dieses Feature unter Linux nicht funktioniert?!
vmwaretools schließe ich aus. Das ist mit und ohne genau gleich, sowohl unter windows als auch Linux. VMHW-Version ist überall min. 7, fast flächendeckend 8. Sollte das Problem also auch nicht sein.
Ehrlich gesagt bin ich etwas ratlos. Hab auch schon bei vmware gefragt, bislang aber noch keine brauchbare Lösung bekommen.

Wir verwenden zur Virtualisierung hauptsächlich vollausgestattete BL460 G6/7/8 sowie ein paar DL980G7 die sogar dedizierte 10GBit Interfaces nur für vmotion haben.

Hat da wer ne Idee dazu. Ich komme eher aus der Windows-Ecke, meine Linux Kenntnisse sind daher eher bescheiden.

Linux-Kenntnisse helfen dir unter ESXi nicht weiter, da der ESXi bekanntlich kein Linux ist.
Wie sieht euer Storage aus und wie habt ihr euer Netzwerk konfiguriert? So wie ich die Sache verstanden habe, hat sich beim Upgrade von 4 auf 5 unter anderem der Kernelport geändert. Möglicherwiese läuft jetzt das vMotion eben nicht mehr über die 10Gig-Leitung wie zuvor.

Hi Dayworker

Die Linuxkenntnisse habe ich jetzt nicht auf die den ESXi bezogen sondern auf meine Linux-Guests, welche dieses komische Verhalten an den Tag legen. Und davon hab ich so ca. 100 Stück.

Ja vmotion läuft bei uns auf einem eigenen Kernel Port (vmk1), vmk0 ist Management und läuft auf den DL980 gemeinsam auf einem eigenen vSwitch welcher 2x10Gbit Aktiv/Standby zur Verfügung hat. Der Management Kernelport ist für mich vernachlässigbar vom Traffic her, da wir auch kein NFS (deren Traffic ebenfalls über vmk0 laufen würde) verwenden.

Auf den Blades haben wir sogar einen exklusiven vSwitch dessen NICs wir via Virtual Connect 3Gbit zugewiesen haben. Aber das machts wohl nicht aus. Das Verhalten ist auf den Blades und den großen Hobeln das gleiche. Dürfte also eine Linux Guest OS Spezialität sein.

Storage schließe ich jetzt auch mal aus. Wir haben grade eine Migration von der großen NetApp FAS 6080 auf eine wesentlich schnellere Hitachi VSP hinter uns. Diese wurde auf ca. 50.000 IOPS gesized und die langweilt sich derzeit noch.

Ach ja. Wir verwenden ausschließlich FC 8G als Storage Anbindung. Die VMWare-Umgebung hat dafür 2x8GB Adapter exklusiv für sich zur Verfügung. Lt. HDS Tuning Manager haben wir ein Grundrauschen von 5000-10000 IOPS bzw. 70-200MB/s auf den Adaptern. Latenzen liegen im Schnitt bei 2-4ms. Soll auch schon Ausreißer von 10ms gegeben haben. Aber im Vergleich zur NetApp bei der wir gerne mal den mittleren 3stelligen gesehen haben ist das Traumhaft.

Wie gesagt, ich glaube es hat irgendwas mit dem GuestOS zu tun. Warum das... Ich habe keine Ahnung