.:Ewig Drohendes Versagen:.

Für den Import werden Zeitzonen Tabellen benötigt welche man hier: https://dev.mysql.com/downloads/timezones.html bekommt.

Diese können dann z.B. mit Heidi oder per Console eingespielt werden.

Problem ist allerdings, dass eine der Spalten „Offset“ heißt und dies eins der SQL Keyword ist….

Abhilfe schafft ein Suchen nach Offset, und ein Ersetzten mit `Offset` – wichtig die richtigen Anführungszeichen hier zu verwenden.

@Google
How to deal with SQL column names that look like SQL keywords?
mariadb offset as colum name
mariadb timezone offset
import timezone in mariadb under windows

Um einen Apple TV 4k im Konferenzraum Modus in die Werkseinstellung zu setzten muss man diesen ca. 5x hintereinander vom Strom trennen + booten lassen. Dann erschein ein Recovery Menü. In diesem kann man MIT der Fernbedienung dann den Factory Reset durchführen.

Also Strom AN -> booten -> Strom AUS -> Strom AN -> booten -> Strom aus ….

So geht der total einfache und intuitive Factory Reset / Werkseinstellungen / Zurücksetzten eines Apple TV 4k im Konferenzraummodus.

Um einen Datastore zum löschen / unmounten auf dem sich die Syslogs eines/mehrerer ESXi Servern befinden muss vorher der Syslog Pfad auf ein anderes Volume geändert werden:

VMware KB Artikel 2004605 -> KLick

SSH auf dem ESX aktivieren und mit Putty verbinden ->

ein
esxcli system syslog config get
zeigt die aktuelle Konfiguration

mit einem
ls -l ../vmfs/volumes/
bekommt man die Datastorebezeichnung etwas Menschenfreundlicher aufbereitet

nun ein beherztes
esxcli system syslog config set –logdir=/vmfs/volumes/***VOLUMEID****/Syslog

und anschließend zum reload der Konfig ein
esxcli system syslog reload

nun klappt auch der Unmount der Datastores.

Das ganze muss natürlich auf allen ESX Servern durchgeführt werden welche ihr Syslog in diesen Datastore schreiben:

–>> Das Upgrade enthält die folgenden miteinander in Konflikt stehenden VIBs:
Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560
Mellanox_bootbank_net-mst_2.0.0.0-1OEM.550.0.0.472560

Die Lösung ist das vib auf den Hosts zu deinstallieren – wenn es denn nicht gebraucht wird:
http://www.virtubytes.com/2017/02/12/esxi-upgrade-conflictiing-vibs-hpe-image/

Kann hier eigentlich nicht mal irgendwas einfach funktionieren? 🙁

Zu Beginn -> Backup / Snapshot des „alten“ vCenters!!

Einen ersten Eindruck des Setups kann man sich hier ansehen:
https://v-punk.com/how-to-upgrade-vcsa-6-0-to-vcsa-6-5/

Wenn man die neue 6.5er Appliance mit dem „alten“ Namen deployen möchte – sollte man die alte VM vorher einfach umbenennen.
Dann ist es natürlich auch nicht verkehrt einen anderen Datastore zu nehmen…

Bevor es wirklich losgeht ->>
1. Überprüfen ob das root Password nicht abgelaufen ist
-> A general system error occurred: vix error codes = (1, 4294967293).
–>> https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2147895

2. Den Migrations Assistenten auf dem Server mit dem Update Manager starten
-> There is no MA extension for VUM available on source VC.
–>> http://pubs.vmware.com/vsphere-65/index.jsp?topic=%2Fcom.vmware.vsphere.upgrade.doc%2FGUID-6A39008B-A78C-4632-BC55-0517205198C5.html

3. Evtl. vorher mal prüfen ob die Datenbank Sequenzen den richtigen Owner haben
-> Database in-place upgrade failed. Please see vcdb_inplace.err and vcdb_inplace.out for details.
–>> https://communities.vmware.com/thread/548057

4. Fehler bei Schritt 3
-> Error attempting Vcintegrity Export file does not exist or is corrupted, abort import
–>> https://communities.vmware.com/thread/546958
—>>>> Bei mir hat ein Reboot der neuen Appliance zumindest eine 6.5er Appliance zurückgelassen auf der alles bis auf den Update Manager migriert war…

Es ist geschafft – das Prüfungszeugnis ist eingetroffen 🙂

Es hat für ein Befriedigend mit einem 2,6er Schnitt gereicht.

Man man – 0,1 an einem Gut vorbei – naja das Ego schläft halt nie ….