Troubleshooting bei vmnic Störungen

Fehlfunktionen sind schlimmer als Ausfälle

Redundanz ist elementar wichtig in virtuellen Umgebungen. Wenn eine Komponente ausfällt, muss eine zweite einspringen und die Funktion übernehmen. Aber was passiert, wenn eine Komponente nicht gänzlich ausfällt, sondern nur nicht mehr richtig funktioniert? In diesem Fall läßt sich die Störung nur schwer erkennen.

Ich wurde kürzlich von einem Freund alarmiert, als er plötzlich den Zugriff auf alle Freigaben seines (virtuellen) Fileservers verlor. Ich verband mich mit einer Service Workstation und begann mit dem Troubleshooting. Dies sind die ersten Diagnose-Ergebnisse:

  • Der Fileserver reagierte nicht auf ping
  • Ping zum Gateway funktionierte
  • DNS Auflösung zu den virtuellen Domaincontrollern funktionierte
  • Eine Browser-Session zu vCenter scheiterte und die vCenter Appliance antwortete nicht auf ping.

Es handelte sich hier um einen kleinen 2-Knoten Cluster auf vSphere 6.5 U2. Vielleicht war ein ESX ausgefallen? Aber dann hätte HA alle betroffenen VMs auf dem verbleibenden Host neu starten müssen. Und das war offensichtlich nicht der Fall. Ich schickte ping Anfragen an beide ESXi Hosts und erhielt von beiden Antwort. Nein, das sah nicht nach einem Host Crash aus.

Als nächstes verband ich mich mittels Hostclient direkt zu den ESXi Hosts. Alle VMs waren aktiv. Ich öffnete eine vSphere-Konsole zur Fileserver VM, konnte mich aber nicht mit Domänen-Login anmelden. Mit einem lokalem Konto funktionierte es. Der Fileserver sah von innen gesund aus munter aus und alle Freigaben waren vorhanden.

Spätestens jetzt wurde klar, dass es sich um ein Netzwerk Problem handeln musste. Jedoch waren alle Uplinks aktiv und verbunden. Wo ist also das Problem?

Ich fand eine VM, welche auf ping reagierte und Verbindung zum Internet hatte und sich auf dem selben Host befand wie Fileserver und vCenter. Ich öffnete eine RDP Sitzung zu dieser VM und konnte von dort alle anderen VMs des Hosts über ping erreichen. Sogar der Webclient von vCenter war erreichbar. Jetzt wurde das Bild klarer. Einer der physischen Uplinks musste ein Problem haben. Nur welcher?

„Troubleshooting bei vmnic Störungen“ weiterlesen

Resilient Network Infrastructure for Virtualization

Network topology 101 for Virtual Infrastructures

I usually don’t like writing about obvious matters. Yes, fire is hot – night is dark and ice is cold. But in recent times I’ve witnessed some network topology designs (?), that made me frown.

I admit, that in some cases the situation is based on a lack of budget or just structures that have grown over years. I can understand that and it’s no shame. It’s my job to give advices and help to re-design.

No matter how many resources you have – if you use them without thinking, it will never be enough.

On the other hand there are environments who boast with high class components that have cost a fortune and which are organized in such an inefficient way that it almost hurts.

This article is not intended as a networking deep-dive. It’s a shallow 101 about network design that should be common knowledge. It’s a guide for the novice but I’d be happy to get responses by experts too.

The Basics

First let’s start with four simple networking requirements for Virtual Infrastructures.

  • redundancy
  • resiliency
  • bandwidth
  • latency

„Resilient Network Infrastructure for Virtualization“ weiterlesen

ESXi Ghost NIC entfernen

Gespaltener Netzwerk-Adapter

Kann eine VM mit nur einem virtuellen LAN-Adapter gleichzeitig in zwei VM-Networks sein? Kann sie nicht! Aber genau dieses Phänomen konnte ich heute beobachten.

ghostnic01Zuerst dachte ich an ein Artefakt, denn die VM hatte in den Settings ganz sicher nur einen vNIC im Netz “VM extern VLAN2”.
ghostnic02
Woher kommt die Verbindung zum Netz “VM intern”, zu dem offensichtlich kein Adapter verbindet? „ESXi Ghost NIC entfernen“ weiterlesen

Upgrade Distributed vSwitch

Mit VMware vSphere4 wurden erstmals Distributed vSwitches eingeführt. Sie schaffen die Möglichkeit, virtuelle Switches unabhängig vom Host zu administrieren.

Im Laufe der Zeit erfahren vSphere Installationen immer wieder Versionsupgrades. Was dabei leider oft vergessen wird, ist die Version des Distributed vSwitch zu aktualisieren. Das ist kein Problem, aber mit neuen Versionen kommen in der Regel auch neue Funktionen hinzu, die man sicher gerne nutzen möchte.

VDS Versionen

  • 4.0 – kompatibel zu ESX 4.0 und höher
  • 4.1.0 – kompatibel zu ESX 4.1 und höher. Unterstützt NIOC und Load-based Teaming.
  • 5.0.0 – kompatibel zu ESX 5.0 und höher. Unterstützt Port Mirroring, NetFlow und User defined resource pools in NIOC
  • 5.1.0 – kompatibel zu ESX 5.1 und höher. Unterstützt erweitertes Port Mirroring und LACP

„Upgrade Distributed vSwitch“ weiterlesen