Autoren-Archiv: admin

vmware „Diese virtuelle Maschine konnte nicht von vSphere HA geschützt werden …“

Veröffentlicht am von — 2 Kommentare ↓

Problem

Nach dem anlegen einer neuen virtuellen Maschine jammer der vSphere[Web]Client herum:

Diese virtuelle Maschine konnte nicht von vSphere HA geschützt werden und daher ist
es möglich, dass HA nicht versucht, sie nach einem Ausfall neu zu starten.

 

Lösung

Es gibt mehrere Ursachen für diesen Fehler. In der Regel stehen diese im Logfile des Fault Domain Manager (FDM), auf dem vCenter unter /var/log/fdm.log. Unter vSphere 5.5U1+ und 6.0+ haben wir häufiger diesen Fehler im Log:

error fdm[PID] [Originator@PID sub=Cluster] stat(/vmfs/volumes/DS-ID/.vSphere-HA/FDM-GUID-NAME) failed with Permission denied

Es scheint so, als ob sich der FDM manches mal nicht ganz sicher ist, wo er den DS-Heartbeat ablegen soll. Und manchmal wir der HB umgelegt, aber der alte Ordner nicht gelöscht. Ist der Ordner noch da, verweigert der FDM den Dienst mit dem oben genannten Fehler.

  1. vSphere HA ausschalten
  2. Den Ordner „.vSphere-HA“ auf den angegebenen Datastore löschen
  3. vSphere Ha wieder einschalten.

Alternativ kann man auch alle unbenutzten .vSphere-HA Ordner löschen (da ist nichts wichtige drin):

rm -rf /vmfs/volumes/*/.vSphere-HA

 

Windows EventID: 36888 – Quelle: Schannel – Warnung 10 – Fehlerstatus: 1203

Veröffentlicht am von — 2 Kommentare ↓

Problem

Seit „einer Weile“ tauchen im Ereignisprotokoll ständig diese Meldungen auf:

Quelle: Schannel

Ereignis-ID: 36888

Ebene: Fehler

Es wurde eine schwerwiegende Warnug generiert: 10. Der interne Fehlerstatus lautet 1203.

Lösung

Das passiert gerne auf Maschinen mit installierten IIS oder Apps mit ausgehenden TLS-Verbindungen. Der Status 10 bedeutet: „TLS1_ALERT_UNEXPECTED_MESSAGE (10)“. Man kann das nachstellen, indem man ein nicht-TLS-Verbindung auf einen TLS-Port öffnet, z.B. mit http://SERVER:443/foo.

Das ist in aller Regel nicht schlimm und nervt nur. Die Verbindung wird auf jeden Fall beendet.

Man kann die Protokollierung des Fehlers in der Cryptoapi einfach deaktivieren, dann ist der Eintrag weg. Den Wert von „EventLogging“ in HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL einfach von „1“ auf „0“ umstellen.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL]
"EventLogging"=dword:00000000

Volume Shadow Copy Fehler: Unexpected error calling routine ConvertStringSidToSid. hr = 0x80070539

Veröffentlicht am von — Keine Kommentare ↓

Problem

Es treten verschiedene VSS-Fehler auf. Einige Volumenschattenkopien sind nicht verfügbar, P2P-Operationen mit dem vmware Converter schlagen fehl oder eine Datenträgersicherung bricht ab.

Die Fehlermeldung im Ereignisprotokoll:

Log Name:      Anwendung
Source:        VSS 
Event ID:      8193 
Beschreibung: 
Volume Shadow Copy Service error: Unexpected error calling routine ConvertStringSidToSid. 
hr = 0x80070539.

Operation: 
   OnIdentify event 
   Gathering Writer Data

Context: 
   Execution Context: Shadow Copy Optimization Writer 
~snip~

Lösung

Uns sind hier zwei verschiedene Ursachen begegnet. Die erste wesentlich häufiger als die zweite.

  1. Der betroffene Computer hat nicht auflösbare SIDs in der lokalen Administratorengruppe. Diese einfach aus der Gruppe entfernen und den Anmeldedienst neu starten. Schon geht wieder alles.
  2. Im Registry-Schlüssel HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList gibt es noch eine oder mehrere Kopien von Registry-Benutzerprofilen (<SID>.bak). Diese rückstandsfrei löschen.

Nach der Fehlerbehebung klappt auch der VSS-Dienst wieder fehlerfrei.