vMotion fails at 21% with error 195887371

How to troubleshoot vMotion issues

Troubleshooting vMotion issues is in most cases a matter of networking issues. I will demonstrate in this case how to trace down the problem and how to find possible culprits.

What’s the problem?

Initiating a host vMotion between esx1 and esx2 passes all pre-checks, but then fails at 21% progress.

Migrate virtual machine:Failed waiting for data. Error 195887371. The ESX hosts failed to connect over the VMotion network.

See the error stack for details on the cause of this problem.
Time: 07.01.2018 19:08:08
Target: WSUS
vCenter Server: vc
Error Stack
Migration [167797862:1515348488969364] failed to connect to remote host <192.168.45.246> from host <10.0.100.102>: Timeout.
vMotion migration [167797862:1515348488969364] vMotion migration [167797862:1515348488969364] stream thread failed to connect to the remote host <192.168.45.246>: The ESX hosts failed to connect over the VMotion network
The vMotion migrations failed because the ESX hosts were not able to connect over the vMotion network. Check the vMotion network settings and physical network configuration. 
Migration [167797862:1515348488969364] failed to connect to remote host <10.0.100.102> from host <192.168.45.246>: Timeout.
vMotion migration [167797862:1515348488969364] failed to create a connection with remote host <10.0.100.102>: The ESX hosts failed to connect over the VMotion network
Failed waiting for data. Error 195887371. The ESX hosts failed to connect over the VMotion network.

„vMotion fails at 21% with error 195887371“ weiterlesen

19. November 201319. November 2013

DeepSecurity 9.0 und vSphere 5.5

Beim Updateversuch eines Testsystems (vSphere 5.1) auf Version 5.5 scheiterte das Upgrade der ESXi Hosts. Das betroffenen Hosts werden mit Trendmicro DeepSecurity 9.0 überwacht und enthalten daher auch die entsprechenden Kernelmodule. Da der Upgradeprozess auf anderen Systemen eine Routineaktion ist, war schnell der Kerneltreiber von DeepSecurity im Fokus.

Not supported

Nachfrage beim Trendmicro Support bestätigte die Vermutung:

Kein Support für DS 9 unter vSphere 5.5
Es wird keinen Patch für DS 9 geben
Komplett neue Architektur notwendig
DS 9.5 wird in Q2 2014 erscheinen (vermutlich April)
DS 9.5 wird nicht mit vSphere < 5.5 kompatibel sein

Das sind schlechte Nachrichten für Kunden von Trendmicro DeepSecurity. Als geschätzter Veröffentlichungstermin wird Q2/2014 (!) genannt. Besonders ärgerlich erscheint mir der letzte Satz. Es bedeutet im Umkehrschluss, daß eine Migration auf DS9.5 und anschließendes Upgrade auf ESXi 5.5 nicht möglich sein wird.

Alternativen?

Mittlerweile ist DeepSecurity nicht mehr das einzige Produkt mit Hypervisor basiertem Virenscan am Markt. McAfee und Kaspersky haben ebenfalls vergleichbare Produkte am Start. Wie ist die Situation bei der Konkurrenz?

McAfee

Das Aktuelle Produkt MOVE 3.0 Agentless ist nicht mit vSphere 5.5 kompatibel. Unterstützung ist für den nächsten Release geplant. Termin noch unbekannt.

Kaspersky

Kaspersky Security for Virtualization 2.0 unterstützt ebenfalls kein vSphere 5.5. Dazu ein Auszug aus den Software Requirements für Version 2.0.

For the File Anti-Virus component to work properly, the VMware virtual infrastructure must meet one of the following software requirements:

VMware ESXi 5.1, VMware ESXi 5.1 Update 1, VMware ESXi 5.0, VMware ESXi 5.0 Update 1, VMware ESXi 5.0 Update 2, or VMware ESXi 4.1 Update 3.

vSphere5: Multi NIC vMotion

Betrachtet man vSphere Cluster im produktiven Einsatz, so fällt auf daß immer noch sehr wenige davon mit 10 GB Uplinks ausgestattet sind. Und das meist aus gutem Grund, denn die Hardware ist sehr teuer und auch die Infrastruktur zwischen den ESX-Knoten (Switches, Router, etc.) muß 10 Gbit unterstützen. In der Regel kann man mit mehreren 1Gbit Uplinks sehr gut auskommen und es bedarf schon einiger Mühe einen 1 Gbit NIC zu sättigen. Einzig bei vMotion kann es gelegentlich zu Engpässen kommen, weswegen von mir in der Vergangenheit der Management Traffic vom VM-Network logisch getrennt wurde und die Adapter nur wechselseitig als Standby zur Verfügung standen.

Eine wirklich tolle Eigenschaft von vSphere5 ist mir aber bis vor kurzem entgangen: Multi-NIC vMotion. Hierbei wird der Datenverkehr über mehrere physische NICs geleitet. Es bedarf mindestens zweier NICs mit je einer VM-Kernel Portgruppe und ähnelt dem Verfahren zum Aufbau einer iSCSI-Portgruppe. Nur daß sich hier beide vmk Portgruppen im selben IP Subnetz befinden. Diese Funktion ist nicht nur bei mehreren gleichzeitigen vMotion Transaktionen nützlich, sonder auch schon bei einer einzelnen.

Manuelle Einrichtung

Wir brauchen dazu entweder zwei vSwitches mit je einem vmnic und je einer vmkernel Portgruppe, oder wir verwenden einen vSwitch mit zwei vmnics und zwei Portgruppen. Letztere Variante gefällt mir persönlich besser.

Einen vSwitch erstellen und diesem zwei NICs zuordnen (Bsp: vmnic1, vmnic2)
zwei vmkernel Portgruppen erstellen (Bsp: vMotion1, vMotion2), mit IP Adressen aus dem gleichen Subnetz.
Switch failover-order umgehen.
vMotion1 mit vmnic1 (active), vmnic2 (standby)
vMotion2 mit vmnic2 (active), vmnic1 (standby)

Achtung Bug!: Derzeit existiert noch ein Problem in vSphere5, wenn zwei Kernelports auf dem selben Virtual Standard Switch vorhanden sind. Das Problem wurde ausführlich im Blogartikel von VMtoday beschrieben und ist ab vSphere5 U1 behoben.

Skriptgesteuerte Einrichtung

Bei mehreren Hosts ist eine Automatisierung wichtig. Die manuelle Einrichtung ist nicht nur mühsam, sondern auch fehleranfällig. Im Diskussionsbereich des Artikels zum Thema Multiple-NIC-vMotion auf Yellow-Bricks werden Skripte in unterschiedlichen Skriptsprachen gelistet. Darunter auch vSphereCLI und PowerCLI.

Links

Frankdenneman.nl: Multi-NIC vMotion support in vSphere5
VMtoday: vSphere 5 Networking Bug #2 Affects Management Network Connectivity
Yellow-Bricks: Multiple-NIC vMotion in vSphere 5
VMware Pubs [PDF]: Networking-Guide

17. Mai 2011

vShield: Problem mit Kernelport

Beim experimentieren mit vShield Endpoint und Deep Security von Trendmicro begegnete mir ein eigenartiges Problem. Immer wenn ich den “Prepare Host” Wizard ausführen wollte, meldete dieser ein Problem mit der VM Kernel VNIC IP. Diese (169.254.1.1) sei nicht identisch mit der in den vCenter Settings des DS-Managers eingestellten IP-Adresse (169.254.50.1). Wie ich auch suchte, ich konnte keinen Kernelport mit der genannten IP im System finden. Nach zäher Suche im Netz fand ich den entscheidenden Hinweis im VMware Forum. Ich hatte natürlich zuvor auch mit der vShield-App experimentiert, die einen vmservice-vswitch konfiguriert hatte. Die vShield-App und der vSwitch war inzwischen entfernt. Übrig blieb ein Relikt in den erweiterten Einstellungen unter Net.DVFilterBindIpAddress, das den Wizard aus der Spur brachte. Denn genau dort war besagte IP 169.254.1.1 hinterlegt.

„vShield: Problem mit Kernelport“ weiterlesen