ugg.li Schnelle Hilfe für schnelle Admins
Nicht immer schön, aber effektiv. Schnelle Hilfe für schnelle Admins.
[…]
Verify that the time has not changed throughout the environment and that no changes to time have been made in the last 24 hours.
[…]
WTF? Zeit anhalten?
Quelle: vmwarekb, Feeback abgeschickt, mal sehen ob das geändert wird. Was gemeint ist, ist mir schon klar, aber diese Formulierung ist interessant 🙂
Wenn der VMWare Converter 5.x länger als gewöhnlich (2 Tage und 8 Stunden) für die Konvertierung einer 250 GB Maschine braucht, dann liegt das unter Umständen an der standardmäßigen Verschlüsselung des Datentransfers.
Die Geschwindigkeit lässt sich durch Ausschalten dieses Features stark erhöhen.
So gehts:
1. converter-worker.xml Konfigurationsdatei öffnen.
ab Vista unter: „%ALLUSERSPROFILE%VMwareVMware vCenter Converter Standalone“
älter: „%ALLUSERSPROFILE%Application DataVMwareVMware vCenter Converter Standalone“
2. Config/nfc/useSsl Schlüssel auf false setzen:[HTML]<nfc>
<readTimeoutMs>120000</readTimeoutMs>
<useSsl>false</useSsl>[/HTML]
3. „VMware vCenter Converter Standalone Worker“ Dienst neustarten
In der Weboberfläche (https://<vcenter-appliance>:5480/) ist das Update der Appliance schnell gestartet:
Leider schlägt das Update bei der Version 5.1 (Build 880472 und kleiner) gerne fehl. Das Update läuft in der Regel in paar Stunden lang (ich habe schon 4-5 Stunden gewartet), im Gegensatz zu den Aussagen von vmware (…“the update process halts for nearly an hour and the update status at Web UI shows as installing updates. However, eventually, the update completes successfully after an hour.“). Schuld ist ein Fehler ist der FIPS-Sicherheitsprüfung der SSL-Module
In der Regel ist das Update trotz langer Wartezeit irgendwann mit diesem Fehler in einem halbkaputten Zustand:
./etc/init.d/vami-sfcb: line 238: 7385 Aborted nohup /opt/vmware/share/vami/vami_sfcb_test > /dev/null 2>&1 ./etc/init.d/vami-sfcb: line 238: 7398 Aborted nohup /opt/vmware/share/vami/vami_sfcb_test > /dev/null 2>&1.failed, restarting vami-sfcbd. Shutting down vami-sfcbd: done. Starting vami-sfcbd: done. Checking vami-sfcbd status:/etc/init.d/vami-sfcb: line 238: 7513 Aborted nohup /opt/vmware/share/vami/vami_sfcb_test > /dev/null 2>&1 ./etc/init.d/vami-sfcb: line 238: 7526 Aborted nohup /opt/vmware/share/vami/vami_sfcb_test > /dev/null 2>&1 ./etc/init.d/vami-sfcb: line 238: 7539 Aborted nohup /opt/vmware/share/vami/vami_sfcb_test > /dev/null 2>&1 ./etc/init.d/vami-sfcb: line 238: 7552 Aborted nohup /opt/vmware/share/vami/vami_sfcb_test > /dev/null 2>&1
Es hilft, VOR DEM UPDATE die SSL-Bibliotheken und Binaries auf den aktuellen Stand zu bringen und die FIPS-Hashes zu löschen. Das geht auch nach oder während eines kaputten Updates, allerdings sollte man das Update danach noch einmal korrekt ganz durchlaufen lassen – das klappt dann meistens auch. Gegen zerstörte Datenbanken hilft die Snapshot-Funktion 🙂
Lösung:
rm /usr/lib64/.lib*.hmac
mount /dev/cdrom /media/ cd /media/update/package-pool rpm -Uvh openssl-* rpm -Uvh libopenssl0_9_8-* rpm -Uvh openssh-5.1p1-* umount /media/
Wenn die Appliance auf dem Upgrade-weg komplett zerschossen wurde, was passieren kann wenn ein Admin die VM wären des Prozesses im falschen Moment hart rebootet, hat mir die Anleitung zum manuellen Update sehr weitergeholfen. Danke @Martin Knaup (http://vaspects.blogspot.de/2013/05/workaround-for-vcenter-server-appliance.html). Das ist zwar unsupportet, aber in der Regel stressfrei und wesentlich sinnvoller als alles neu zu bauen – je nachdem wieviele Replikationsjobs, Backups, Regel und so weiter an dem vCenter dranhingen.
Unter umständen schlägt die Konvertierung von frischen physikalischen Servern bei 1% mit dieser unfreundlichen Fehlermeldung fehl:
Fehler: Die IP-Adresse der virtuellen Zielmaschine, die den Converter-Hilffsserver ausführt, kann nicht ermittelt werden.
Grund war bei mir eine „gestörte“ Netzwerkkommunikation zwischen der Converter-Ausführenden Maschine und dem ESX-System. Noch genauer war das hier ein router-Isolationsmodus, bei dem der (vermeintliche) Switch das Ethernet nicht sauber bridged, sondern nur IP zulässt.
Der Fehler lässt sich abe auch prinzipiell mit jeder Firewall zwischen Converter und ESX reproduzieren. Also immer prüfen:
Für den Fall, das es keinen DHCP im physikalischen LAN an dem converter-Zielnetz (des neuen Gastes) gibt, muss die Adresse für die Converter-Hilfsmaschine sowiso manuell unter „erweitert“ eingegeben werden.
Manchmal erscheint im Aufgabenbereich des vSphere Cients eine ganze Liste an „Festplattenbreich zuordnen“ Aufgaben. Ab und an sogar beinahe im Sekundentakt. In der englischen Version des vSphere Clients heisst die Meldung „Map Disk Region“. Der Effekt tritt gehäuft auf, wenn eine Datensicherung über die VCB-Schnittstelle gemacht wird, vor allem (natürlich) bei Drittanbieter-Backup-Software.
Tipp: Der vSphere-Client ist immer Multilingual. Die englische Version lässt sich auch auf einem Deutschen Windows jederzeit durch Anhängen des Parameters „-locale en_US“ starten. In vielen Fällen die englische Beschreibung eindeutiger und das googeln nach Fehlern bringt mehr Ergebnisse.
Englisch:
Deutsch:
Lösung: Dieser Eintrag ist an sich erst einmal rein informell und hat keinen Einfluss auf Performance oder den Systemstatus. Die Ursache ist (meist) eine stark fragmentierte VMDK; jeder „Zuordnen“-Eintrag stammt aus dem Blockzugriff auf ein Dateifragment auf ein gelocktes virtuelles Volumen. In den meisten Fällen ist ein sehr großer (oder viele kleine) Snapshot(s) des Volumens die Ursache.
Fast immer hilft:
Wenn das noch nicht hilft, ist es schlimmstenfalls notwendig das (und alle anderen fragmentierten) Volumen von dem Datastore auf einen anderen zu verschieben und zurückzuschieben.
Es gibt mittlerweile auch einen öffentlichen VMware KB-Artikel dazu.