Firmware-Upgrade HP StorageWorks SAN Switches (4/4, 8/8)

Veröffentlicht am von — 7 Kommentare ↓

Die HP StorageWorks Fibre Channel-Switches werden in der Regel in einer Fabric Switch-Umgebung über Switches oder indirekt über die Directors angesteuert. Mehr gibt es dazu in der Wikipedia (und soll auch nich tInhalt dieses Artikels sein). Die SAN Switches StorageWorks 4/8, 8/8 und die anderen Geräte dieser Serie von Hewlett-Packard beinhaltet eine kleine Linux Distribution als Firmware, die auch ihre Update braucht. Achtung! Je nach Stand des Systems kann nicht immer direkt auf die allerneueste Version aktualisieren kann. Die Dokumente zu „Upgrade-Pfad“ beschreiben die notwendigen Versionsschritte. In der Regel müssen alle Releases mitgenommen werden, ab und an noch ein Update dazwischen (zum Beispiel hier: 5.9.x › 6.0.x › 6.1.x › 7.x.x). Ob ein Upgrade grade möglich ist, überprüft die Routine aber automatisch und wirft passende Fehler aus wenn das grade mal nicht geht. Jedes Upgrade erfordert zeingend einen Reboot des Switches. Ein Update nicht im laufenden Betrieb vorzunehmen ist empfohlen. Echte Männer machen das natürlich im (redundanten) Produktivbetrieb, aber man sei sich der Folgen bewusst wenn mal ein Storage für ~30 Sekunden komplett aussteigt.

Lösung:

  1. Updates herunterladen. Für den 8/8er Switch geht das beispielsweise hier. Ja, die „Firmware-Updates“ sind ~900Mb groß. Danke Java.
  2. FTP-Server starten und vorbereiten. Ich persönlich nutze gene den IIS den Windows sowiso im Gepäck hat, aber ein Filezilla oder ähnliches tut es natürlich genauso. Der Servermuss auf den Standardport 21 lauschen.
  3. Firmware ins root („/“) des FTP-Servers entpacken (nicht in ein Unterverzeichnis). Es landen da also ganz viel Ordner drin wie SWBD21, SWBD55, SWBD62 und so weiter.
  4. Die Verwaltungsoberfläche des Switches starten, als Administrator anmelden (HP San Switches bis 8/16 Default Passwort: admin/password danach admin/fibranne)
  5. Den Switch-Admin starten, oben rechts über ‚Show Advanced Mode‘ den Tab ‚Firmware Download‘ anzeigen lassen und öffnen
    1. Hostname oder IP: Adresse des Host mit dme FTP-Server
    2. Name/Kennwort
    3. Der Firmware-Patch lautet „release.plist“. Nicht fragen.
  6. Fertig 🙂

Update aus den HP-Release-Notes:

Upgrading from Fabric OS 5.0.x to 5.2.3 is supported
Upgrading from Fabric OS 5.1.x to 5.3.1a is supported, but upgrading from Fabric OS 5.0.x or a previous release directly to 5.3.1a is not.
Upgrading to Fabric OS 6.0.0b is only allowed from Fabric OS 5.3.x. (6.0.0c is a special upgrade version, only meant to be used in between firmware upgrades)
Upgrading to Fabric OS 6.1.2b is allowed only from Fabric OS 6.0.0b
Upgrading to Fabric OS 6.2.2f is allowed only from Fabric OS 6.1.0a or later.
Upgrading to Fabric OS 6.3.2d is allowed only from Fabric OS 6.2.0a or later.
Upgrading to Fabric OS 6.4.2b is allowed only from Fabric OS 6.3.x.
Upgrading to Fabric OS 7.0.2 can be done non-disruptively from Fabric OS 6.4.1a or later.

Update aus dem Admin-Netzwerk:

BS sagt: IBM und ein paar andere OEMs verkaufen die selben Brocade FC-Switches. In aller Regel läuft ein HP-Firmware-Upgrade auch genau so auf den IBM-Geräten; lieber sind mir in den meisten Fällen die HP-Pakete, denn HP pflegt die Produkte wesentlich schneller und umfassender als IBM.

vSphere: Dieser Host verfügt momentan über keine Verwaltungsnetzwerkredundanz

Veröffentlicht am von — 1 Kommentar ↓

Auf manchen vmware vSphere Hosts macht sich diese Fehlermeldung im gelben Informationsbereich bemerkbar und versetzt den Host auch noch in den fiesen be-Warndreieckten Warnstatus:
vsphere_ha_host-keine-verwaltungsnetzwerkredundanz_fehler

"Dieser Host verfügt momentan über keine Verwaltungsnetzwerkredundanz"

Die Meldung stammt von dem eifrigen Management-Agent des ESX Hosts und hat eigentlich einen guten Grund. Das Verwaltungsnetzwerk („Management Network“) sollte (dringend) mit mindestens zwei Netzwerkkarten angebunden sein, denn sonst könnte ein Gast mit viel Traffic (sofern im selben Netzwerk) das Management erheblich stören. In der wundervollen heilen vmware-Welt hat natürlich jeder Host mindestens zwei Netzwerkkarten für die Verwaltung, zwei oder mehr für vmotion, eine für den Cluster-Takt (und vielleicht FT) und dann noch mindestens vier für Gastsysteme – pro Netzwerk versteht sich. Da Hosts mit neun oder mehr Netzwerkkarten in der KMU-Welt mit unter zehn ESX-Hosts eher selten anzutreffen sind, erübrigt sich diese Warnung in vielen Fällen.

Sollte diese Meldung einmal trotz redundanter Anbindung auftauchen und nicht wieder freiwillig verschwinden, hilft oft einer dieser beiden Tricks:

  • Entfernen einer der beiden Netzwerkkarten von dem virtuellen Management-Switch, dann erneutes hinzufügen … 20 Sekunden warten.
  • Oder: Rechte MT auf den host un „HA-Agenten neu konfigurieren“

Sollte das nicht helfen, tut aber auf jeden Fall die rohe Gewalt:

  1. Eigenschaften des Clusters öffnen
  2. vSphere HA -> Erweiterte Optionen
  3. Hinzufügen der neuen Option: 
     das.ignoreRedundantNetWarning   True
  4. Ok -> OK -> OK -> HA-Agent neu konfigurieren.

vsphere_ha_host-keine-verwaltungsnetzwerkredundanzDann ist die Warnung weg und erscheint auch bei keinem Host im ganzen Cluster wieder. jemals. auch nicht, wenn Sie recht hätte.

Veeam: „Host with uuid ‚xxxx-xxxx-xxx‘ was not found“ nach Hostupdate (oder Hardwareänderung)

Veröffentlicht am von — Keine Kommentare ↓

Bei einem vSphere Update bekommt der jeweilige Host eine neue UUID. Das ist auch vollkommen korrekt so. Veeam verwaltet aber seine Lizenzen nach diesen UUIDs, was nach einer Hostupdate zu der irreführenden Fehlermeldung führt:

Veeam: "Host with uuid 'xxxx-xxxx-xxx' was not found"

Lösung: Zurücksetzen der Veeam-Lizenzen für den passenden Host.veeam_lizenzen_zuruecksetzen

  1. Dash -> Help -> License Information
  2. Licensed Hosts
  3. Host auswählen und „revoken“

 

 

Beim nächsten Backup (oder Replikation) werden die freien Lizenzen wieder neu vergeben.

vSphere Appliance VC_CFG_RESULT=302(Error: Enabling Active Directory failed.)

Veröffentlicht am von — 1 Kommentar ↓

Ab und an kommt es bei der Inbetriebnahme einer vSphere 5 oder 5.1 Appliance zu dem folgenden Fehler:

VC_CFG_RESULT=302(Error: Enabling Active Directory failed.)

Dieser kann mehrere Ursachen haben. Fehlersuche:

  • Ist die vCenter Applicance mit dem richtigen LAN verbunden, hat es eine korrekte IP-Adresse, eine passende Subnetzmaske und/oder passeden routen zu DNS/AD-DCs? (vSphere Clients, VM bearbeiten, Netzwerk – danach https://<vcnetername>:5480)
  • Hat die Adresse der Appliance schon einen korrekten DNS-Hosteintrag und den passenden reversen Pointer für diesen Namen (als einziges)? Der Eintrag muss tatsächlich dem Namen der Appliance entsprechen, sonst schlängt die Zertifikatsprüfung fehl und es darf nicht mehrere geben

    .

  • Steht bei der Benennung der Appliance (https://<vcentername>:5480 – Network) der ganze FQDN drin?
  • Ist bei der Angabe der Active Directory Domain der vollständige FQDN der Domäne eingegeben?
  • Steht die Zertifikatsgenerierung (System – Toggel Vertificate genration) vielleicht auf „no“? Die sollte auf ‚yes‘ stehen, bis alles läuft.
  • Ab und zu hilf es, den Admin-UPN (administrator@domä.ne) zu verwenden, anstalle des einfachen Benutzernamens.
  • REBOOT. Nach der Integration Rebooten, sonst funktioniert die Auswahl nicht oder das domänen-Feld bleibt gleich ganz leer.

Nach Prüfung aller dieser Ursachen kommt eigentlich nur noch DNS oder ein falsches Administrator-Kennwort in Frage. Im Internet kursieren Tipps, den Hostnamen des vCenter Servers manuell im AD anzulegen. Das ist nicht notwendig, die Vertrauensstellung wird selbstständig erzeugt. Wenn alles korrekt funktioniert.