Archiv der Kategorie: VMware

vSphere Client auf DC installieren

Veröffentlicht am von — 4 Kommentare ↓

Problem

Der vmware vSphere Client ab Version 5.1u1 lässt sich nicht mehr freiwillig auf einem Domänencontroller installieren. Versucht man das, erhält man folgende Ferhlermeldung:

„vSphere Client erfordert Windows XP XP2 oder höher. vSphere Client kann auf dem Domänencontroller nicht installiert.“

vsphere-client-auf-dc-installieren

Lösung

Aufgrund der Microsoft-Vorgabe „Always Isolate DC Role“, der auch grundsätzliche zuzustimmen ist, hat vmWare den OS-Check in den MSI-Wrapper eingebaut. Selbstverständlich lässt sich das (auf eigene Gefahr) auch umgehen. Der Client läuft auch stressfrei auf einem DC.

  • Plattform-Installer (~100mb) aus dem Globalen Installert (~350MB) befreien. Dazu einfach das Paket ganz normal aufrufen un den „viclient-setup.exe“ aus %temp%\{langeinummer} wegkopieren. Danach den Installer nach der Fehlermeldung wieder schliessen.
  • Den Installer aufrufen mit: viclient-setup.exe /VSKIP_OS_CHECKS=“1″

Update: Ein vmware Engineer sagt zu diesem Installer folgendes (Zitat):

We did this deliberately to enforce a Microsoft standard that our guys agree with – don’t install software on a DC, but they made that decision in isolation. Nothing more than that.  So use the workaround safely and hopefully we can undo this in the future.

„Cannot run upgrade script on host“ beim vSphere Upgrade

Veröffentlicht am von — Keine Kommentare ↓

Problem

Das In-Place-Upgrade eines ESXi5.1 Hosts auf 5.5 schlägt mit der Meldung „Cannot run upgrade script on host“ fehl. Das selbe passiert beim Update über den Update Manager. Der Host bootet nach der Fehlermeldung das alte vSphere 5.1 neu.

Lösung

In /var/log/vua.log auf dem Updateserver (oder lokal) ist folgende Fehler protokolliert:

VUA exiting
Alert:WARNING: This application is not using QuickExit(). The exit code will be set to 0.@ ~/vim/lib/vmacore/main/service.cpp:147

Es gibt offenbar zwei Lösungen die hier helfen können

  1. HA-Agent komplett (!) neu installieren („Neu konfigurieren“ reicht nicht:
    1. Host aus dem Cluster entfernen und herunterfahren (!)
    2. Nach einem reboot auf dem betroffenen Host den Agenten lokal über eine Kopie des uninstall-Script deinstallieren: 
      cp /opt/vmware/uninstallers/VMware-fdm-uninstall.sh /tmp
chmod +x /tmp/VMware-fdm-uninstall.sh & /tmp/VMware-fdm-uninstall.sh
    3. Host rebooten, neu zum Cluster hinzufügen, fertig. Jetzt läuft das Update durch. (Quelle)
  2. Bei der Meldung „Remediation failed due to non mmode failure“ ist das Verzeichnis /bootbank/state.* nicht leer.
    1. Im vua.log findet sich die ID der Maschine; die passende state-file einfach entfernen und erneut versuchen.(Quelle)

vmware Aufruf von „HostServiceSystem.Stop“ für Objekt „serviceSystem-8145“ ist fehlgeschlagen

Veröffentlicht am von — Keine Kommentare ↓

Problem

Der SSH-Dienst lässt sich auf einem vSphere Host nicht beenden. Zudem wird die Warnung „SSH wurde für diesen Host aktiviert“ auf dem Übersicht-Tab angezeigt und der Host wird in der Übersicht nur noch it einem gelben Warnsymbol angezeigt.
hostservicesystem-stop-ssh-fehlgeschlagen

Aufruf von "HostServiceSystem.Stop" für Objekt "serviceSystem-8145" auf vCenter Server "vcenter" ist fehlgeschlagen.

Lösung

  1. SSH-Sitzung zu dem betroffenen Host öffnen
  2. Backup der services.xml anlegen: 
    cp /etc/vmware/service/service.xml /etc/vmware/service/service.backup
  3. Die 
    sshServer

    Zeile aus der Datei service.xml löschen, speichern, schliessen

  4. Firewall/Servicemanager die Konfiguration neu einlesen lassen (oder Host rebooten) 
    esxcli network firewall refresh

Das wars, jetzt klappt das Starten und Stoppen des SSH-Dienstes auch wieder via vSphere Client. Update: Es gibt sogar einen offiziellen KB der dieses vorgehen suported.

Lösung 2: Aber ich will doch SSH verwenden!

Die Warnung lässt sich auch generell pro Host abschalten.

  1. Den betreffenden Host auswählen -> Konfiguration -> Erweiterte Einstellungen
  2. Ganz nach unten zu „UserVars“ scrollen und den Wert „UserVars.SuppressShellWarning“ auf „1“ stellen.

Dann ist die Warnung sofort verscheunden und kommt auch nicht wieder.

NetAPP FAS schreibt sehr langsam Veeam reversed-incremental Backup-Jobs

Veröffentlicht am von — Keine Kommentare ↓

Problem

Mit Veeam Backup and Replication geschriebene Sicherung von von virtuellen Maschinen (vmware oder Hyper-V) sind sehr langsam, wenn diese Faktoren zusammenkommen:

  • NetAPP Storage via CIFS
  • Sicherung im Reversed-Incremental Modus
  • Veeam B&R 6 oder 7

Lösung

Die CIFS-Sitzungsdaten in NetAPP Filern sind im Auslieferzustand für Windows 2000, IIS6 und SQL Server 2000 konfiguriert und lassen viele performancekritische Optimierungsmöglichkeiten vermissen, die Veeam nutzt.

Diese Einstellungen haben sich als „best practice“ erwiesen:

options cifs.max_mpx 1124
options cifs.tcp_window_size 2096560
options cifs.neg_buf_size 65535
options raid.mirror_read_plex_pref alternate