vSphere ESX(i) 5.1 vpxa manuell entfernen

Aus Gründen kann es ab und an mal vorkommen, dass ein vCenter Server entfernt werden musste – zum Beispiel physikalisch. Die übriggebliebenen ESXi-Hosts bleiben in so einem Fall stets der Meinung, auch weiterhin von dem vCenter Server verwaltet zu werden:

Dieser Host wird derzeit von vCenter Server uner der Adresse 1.1.1.1 verwaltet. Änderungen die Sie während dieser Sitzung am Host vornehmen, werden in aktuellen vSphere-Clientsitzungen mit vCenter Server möglicherweise nicht wiedergespiegelt“

Mit einem neuen vCenter Server lassen sich diese Hosts zwar sofort wieder verbinden, aber was passiert wenn es keinen vCenter Server mehr gibt? Um die lästige Meldung loszuwerden reichen zum Glück ein paar Schritte.

Lösung:

  1. SSH Server starten und den Zugriff erlauben (Konfiguration -> Sicherheitsprofil)
  2. Via SSH (z.B. mit PuTTY) am Host als root (oder Benutzer mit Rechten) anmelden
  3. Die vpxa Config bearbeiten (/etc/vmware/vpxa/vpxa.cfg)
    vi /etc/vmware/vpxa/vpxa.cfg
  4. Die ganze Sektion „<vpxa>“ bis „</vpxa>“mit Inhalt entfernen und mit :wq speichern/beenden. Sollte vi der Meinung sein, das die Datei viel zu schreibgeschützt sei, lässt sich dieser mittels einem
    chmod +w /etc/vmware/vpxa/vpxa.cfg

    aufheben.

  5. Vpxa und vmware Hostd neu starten
    /etc/init.d/vpxa restart
    /etc/init.d/hostd restart

    Dann den vSphere Client neu verbinden, fertig.

vpxd „Inventar“ auf vCenter Server 5.1 startet nicht

Der vpxd startet beim vCEnter-Boot nicht mit und braucht ewig lange Zeit?

Lösung: Der vpxd-Service startet nicht ohne verbundene Netzwerkkarte – die virtuelle Netzwerkkarte einfach auf einen (beliebigen) Port legen auf das die Karte beim booten „up“ zurückmeldet und schon startet auch der Inventardienste wieder schnell mit.

Veeam: FLR oder InstantRecovery Jobs werden nie beendet

Einmal gestartete Restore-Jobs sind recht hartnäckig: hat einer der Backup-Proxys einmal einen Job, führt dieser diesen vermeintlich auch fast unstoppbar aus. Für immer.

Das geschieht gerne dann, wenn man Maschinen in einer solchen Vorgang neu startet und das UI nicht mehr synchron mit der SQL-Datenbank ist. Das ist zum Beispiel reproduzierbar, indem man Proxy und Repositories ihren Job machen lässt und den Backup-Server mittendrin neu startet.

So behebt man diesen „Läuft noch“ Zustand:

  • SQL Management Studio starten
  • Verbinden mit der passenden Instanz (z.B. SERERNAMEVEEAMSQL2008R2)
    • Windows Authentifizierung nutzen
  • Neue Query in der Veeam-Datenbank „VeeamBackup“ ausführen:

[sql]
UPDATE [ReportRestoreSessionsAndTaskSessionsView]
SET „state“ = -1
WHERE „initiator_name“ not like ’null‘
[/sql]

Schon passen der UI-Status und die Tätigkeit des Systems wieder richtig zueinander. Quelle: Veeam-KB

Veeam: „Cannot use CBT: Soap fault, endpoint”

Veeam beendet auf einmal manche Sicherung mit Warnungen. Ein Blick ins Protokoll (oder den Bericht) offenbart:

Cannot use CBT: Soap fault. Error caused by file
/vmfs/volumes/4ae0811c-f0f34f24-0f3b-00237ddef82c/Computername/Computername.vmdkDetail: '', endpoint: ''

Dies bedeutet das das Change Block Tracking keine geänderten Datensätze identifizieren kann.

Die folgenden Schritte müssen auf jeder virtuellen Maschine durchgeführt werden die mit Warnungen im Status der Sicherung aufgeführt wurden.

  1. Fahren Sie die virtuelle Maschine herunter
  2. Rechte Maustaste auf Maschine und Einstellungen bearbeiten
  3. Reiter Optionen wählen, Erweitert – Allgemein – Konfigurationsparameter

  4. Setzen Sie den Eintrag „ctkEnabled“ auf false
  5. Setzen Sie den Eintrag“scsi0:x.ctkEnabled“ für jede Festplatte auf false
  6. Öffnen Sie das Quellverzeichnis der virtuellen Maschine und löschen alle –CTK.VMDK Dateien
  7. Starten Sie die virtuelle Maschine
  8. Fahren Sie die virtuelle Maschine wieder runter. Dies ist wichtig um die CTK zu aktualisieren
  9. Starten Sie die virtuelle Maschine
  10. Starten sie den Backup Job um das CBT zu aktivieren

Siehe auch http://www.veeam.com/KB1113

vmware vSphere Client „Die VMRC-Konsole hat die Verbindung getrennt“ unter Windows 8

Unter Windows 8 schon mal versucht im vSphere Client (bis Version 5.0.0 build 455964, also 4.0, 4.1 und 5.0) eine Konsolensitzung zu öffnen? Das funktioniert nicht, mit der Meldung:

Die VMRC-Konsoel hat die Verbindung getrennt ... Versuch einer Neuverbindung...

Die Konsole geht trotz des „Neuverbindungsversuchs“ nicht auf – und das wird Sie auch nie.

Das liegt daran, das die VMRC (remote-console) das Konsolen-Internet-Explorer-Plugin nutzt, das unter dem IE10 von Windows 8 (noch) nicht läuft. Sprich: es gibt im Moment unter Windows 8 einfach keine vSphere 4.x Konsole. Interessanterweise funktioniert der Rest des Clients einwandfrei.

Die einzige Möglichkeit (im Moment) ist ein Windows XP mit vSphere Client dabeizuhaben oder vor dem windows 8 -Upgrade schlau genu gewesen zu sein, den direkten VNC-Zugriff auf die Gäste einzurichten.

UPDATE: Das Update auf den vSphere Client von vSphere 5.1 löst dieses Problem. Mit dem 5.1er Client kann man wieder auf alle Konsolen direkt zugreifen. Danke Simon für den Tipp und Hinweis.

Wir haben auch insgesammt gute Erfahrungen mit dem 5.1er Update gemacht und empfehlen Kunden wie Partnern bisher fast uneingeschränkt das Update. Die aktuelle Veeam-Release kann auch (endlich wieder) komplette 5.1er Infrastrukturen sichern (Veeram 6.1 konnte nur vSphere 5.1 Hosts sichern, keine Infrastruturen).