the Sky is the Limit
Ein PING Fehler bei Veeam Sure Backup “DestinationHostUnreachable” kann aufgrund von Automatic Private IP Addressing (APIPA) auf dem virtuellen LAN Adapter auftreten. Obwohl die live-VM eine statische IP Adresse hat, geht diese beim Vorgang des SureBackup verloren, wechselt zu DHCP und produziert oben genannten Fehler.
Das Problem ist bei vmware unter KB1020078 bekannt.
Ein ausführlicher Bericht ist im Blog der PepperCrew zu lesen.
Einrichtung von Zonen auf einem Brocade 300 FC-Switch.
Diese Anleitung geht von einer Neueinrichtung aus, kann aber prinzipiell zur Erweiterung einer vorhandenen Zonenkonfiguration verwendet werden.
Eine Zonierung auf Basis der WWN hat den Vorteil, daß die Fasern an beliebigen Ports des Switches angeschlossen werden können. Dem gegenüber steht ein gewisser Mehraufwand bei der Einrichtung. „Zoning Brocade 300“ weiterlesen
Eine defekte USV soll getauscht werden. Alle Komponenten sind redundant mit Strom versorgt (ein Netzteil an USV, das andere direkt am Stromnetz). Vor der Abschaltung der USV kommt es zu einem kurzen Ausfall im Stromnetz. Die USV ist zu schwach um auch nur diese kleine Schwankung abzufangen. Die Folge: Ein Blackout der vSphere Infrastruktur (ESXi, Storage, Fabric, LAN). Prinzipiell ärgerlich, aber kein Problem. Denn auf allen ESXi Knoten waren zuvor Startreihenfolgen definiert, die genau regeln sollten wann welche VM startet. Leider starteten die ESXi Knoten alle vorher laufenden VMs praktisch zeitgleich, was zu einer erheblichen Belastung der Storage führte (Boot-Storm).
Man muss hier zwei unterschiedliche Szenarien unterscheiden:
Letzteres trifft auf den oben beschriebenen Fall zu. D.h. HA bemerkt hier, daß es zu einem Crash kam und versucht alle zuvor aktiven VMs neu zu starten. Die Startreihenfolge auf ESX Ebene ist hier ohne Belang. Alleine HA ist jetzt für den Neustart verantwortlich. Den Ablauf der Ereignisse unter vSphere 5 hat Duncan Epping kurz in einem Artikel skizziert.
Wie kann man steuern, daß nach einem solchen Ausfall nur die Kerndienste neu starten? Eine vor dem Crash zufällig laufende Test-VM sollte z.B. auf keinen Fall unnötig Last auf die Storage bringen und ausgeschaltet bleiben bis sie jemand manuell startet. Die Lösung liegt in den HA Clustereinstellungen.
Unter VM restart priority gibt es vier Optionen:
Wenn ESXi Hosts ihre Autostartreihenfolge “vergessen”, dann liegt es oft daran, daß nach der Änderung die Management-Agent nicht neu gestartet wurden. Die Folge sind nicht startende VMs nach einem Kaltstart.