cd ~/

Home of Daniel Graf

Benutzer-Werkzeuge

Webseiten-Werkzeuge


Seitenleiste

cd ~/

Home of Daniel Graf

Seiten

Suche

Blog Meta

Dynamo Dresden

Galerie

blog

Blog

VMware - Passwort eines ESXi Users via vCenter ändern

Heute früh hat mich ein vCenter mit der Meldung begrüßt, dass sämtliche Hosts nicht mehr mit dem angehängten Host Profil übereinstimmt. Die Hintergründe dafür sind nicht weiter relevant. Problematisch wurde es nur, dass die Abweichung meinen administrativen ESXi Nutzer betraf, bzw. dessen Passwort. Die Anmeldung via SSH am ESXi Host zeigte, dass mein mir bekanntes Passwort nicht mit dem Passwort auf dem ESXi übereinstimmte. Das Passwort für den root User hatte ich nicht, konnte so also auch nicht meinem User das Passwort ändern.

Da aber der ESXi Host über das vCenter angebunden ist, lässt sich auf die ESXCLI zugreifen und dort das Passwort ändern. Mittels PowerCLI sieht das dann so aus:

Connect-VIServer -Server vcenter.vsphere.local

$EsxCli = Get-EsxCli -VMHost ( Get-VMHost esx01.vsphere.local )
$EsxCli.system.account.set("Supportuser", "supportuser", "<password>", "<password>")

Disconnect-VIServer -Server vcenter.vsphere.local -Confirm:$false

Der Methode set() müssen 4 Parameter übergeben werden:

  1. Description des Users
  2. Username
  3. Passwort
  4. Passwort Wiederholung

Mittels…

$EsxCli.system.account.list()

…kann man sich vorher auch die Liste der Nutzernamen und deren Description ausgeben lassen.

Sofern die Änderung erfolgreich war, wird ein simples true zurückgegeben.

2019/02/05 10:26 · Daniel Graf · 0 Kommentare

VMware - Soft VM/host affinity DRS Regel schlägt fehl

Bei einem Kunden habe ich heute folgende Meldung im vCenter gesehen: The cluster contains no hosts satisfying the soft VM/host affinity rules constraint for VM XXX.

In der DRS Übersicht des Clusters sieht die Meldung so aus:

Wie sich herausgestellt hat (und auch via VM Events nachvollziehbar war), wurden die VMware Tools installiert / aktualisiert. Das Setup wurde aber nicht erfolgreich beendet:

Hier musste die VM heruntergefahren und wieder neu gestartet werden, damit die Meldung verschwand.

2019/02/04 11:11 · Daniel Graf · 0 Kommentare

VMware - vCenter vpxd Events an Syslog Server melden

In meinem vCenter 6.5 wollte ich die vpxd Events in mein Monitoring einbinden, da dort wichtige Meldungen aufschlagen. Die Syslog Einstellungen über den Web Client haben die Events aber nicht übertragen.

Die vpxd Events werden nämlich in der /etc/rsyslog.conf explizit verworfen:

# vpxd-event
# Do not store events because of burst/size concerns
if $fromhost contains $$myhostname and
   $app-name == 'vpxd' and
   $msg startsWith ' Event ' then stop
if $fromhost-ip == '127.0.0.1' and
   $app-name == 'vpxd' and
   $msg startsWith ' Event ' then stop

Um trotzdem die Meldungen zu erhalten, genügt es dort seinen eigenen Remote Syslog Server einzutragen:

[...]

# vpxd-event
# Forward vpxd events to monitoring host
if $fromhost contains $$myhostname and
   $app-name == 'vpxd' and
   $msg startsWith ' Event ' then @@mon.local.lab:514

# Do not store events because of burst/size concerns
if $fromhost contains $$myhostname and
[...]

Anschließend noch den Dienst neu starten:

systemctl restart rsyslog

Allerdings muss man beachten, dass die Änderung durch VMware Updates überschrieben wird - die Config wird nach /etc/rsyslog.conf.old verschoben!

2019/02/01 08:28 · Daniel Graf · 0 Kommentare

VMware - vCenter/PSC friert beim Aushängen eines ISOs ein

Zuletzt hatte ich ein vCenter und einen external PSC via ISO aktualisieren müssen, da kein Zugriff auf das Internet Repository gegeben war. Nach den Updates wollte ich das eingehängte ISO wider aushängen. Beim vCenter ist war der Web Client nicht mehr verfügbar, die SSH Verbindung war weg und auch ein PING war nicht mehr möglich.

Erst nach einigen Minuten waren alle Funktionen wieder gegeben - einen Neustart hat das vCenter übrigens nicht gemacht. Die System Uptime hat sich nicht geändert. Beim PSC war genau das gleiche zu beobachten. Hier kam im Web Client aber noch die Frage auf, ob die CD-Laufwerkssperre des Betriebssystems ignoriert werden soll oder nicht.

Beim Blick auf den PSC musste ich feststellen, dass das ISO nicht im Gast Filesystem gemountet war, also auch kein Zugriff mehr erfolgte. nachdem ich das CD-Laufwerk „geöffnet“ habe…

root@psc01 [ ~ ]# eject -v
eject: using default device `/dev/sr0'
eject: device name is `/dev/sr0'
eject: /dev/sr0: not mounted
eject: /dev/sr0: is whole-disk device
eject: /dev/sr0: trying to eject using CD-ROM eject command
eject: CD-ROM eject command succeeded

…konnte das ISO auch im Web Client erfolgreich ausgehängt werden. Ebenso dann auch beim vCenter.

2019/01/30 13:02 · Daniel Graf · 0 Kommentare

VMware - VCSA 6.5 mit Zertifikat auf eigener CA betreiben

Letztens war ich für einen Kunden aktiv, der eine VCSA in Version 6.5 eingesetzt hat. In dieser wollte er ein SSL Zertifikat einrichten, welches seine Windows CA ausgestellt hat. Anleitungen, wie man dabei vorgeht, gibt es ja von VMware:

Der Kunde und ich haben die Anleitungen strikt befolgt, mit dem Ergebnis dass die VCSA mit dem neuen Zertifikat der Windows CA lief und auch keine Zertifikats-Fehler im Browser auftraten. Allerdings konnten ab dem Zeitpunkt eingesetzte 3rd Party Tools sich nicht zur VCSA verbinden (mit dem VMware Zertifikat war dies kein Problem). Die Logs der 3rd Party Tools waren nicht sehr aufschlussreich, zumal ein curl Zugriff von den Appliances aus unproblematisch waren.

Wie sich am Ende herausgestellt hat, hat uns die VMware Doku in die Irre geführt. Im KB Artikel 2112277 (Replacing a vSphere 6.x Machine SSL certificate with a Custom Certificate Authority Signed Certificate (2112277)) steht geschrieben:

Note: If you have one or more intermediate certificate authorities, the root64.cer should be a chain of all intermediate CA and Root CA certificates.The „machine_name_ssl.cer“ should be a full chain for certificate+inter(s)+root.

The machine_name_ssl.cer should be a complete chain file similar to:
-----BEGIN CERTIFICATE-----
MIIFxTCCBK2gAwIBAgIKYaLJSgAAAAAAITANBgkqhkiG9w0BAQUFADBGMRMwEQYK
CZImiZPyLGQBGRYDbmV0MRYwFAYKCZImiZPyLGQBGRYGbW5uZXh0MRcwFQYDVQQD
Ew5tbm5leHQtQUQtMS1DQTAeFw0xMzAyMDExNjAxMDNaFw0xNTAyMDExNjExMDNa <-----Certificate
SMhYhbv3wr7XraAnsIaBYCeg+J7fKTFgjA8bTwC+dVTaOSXQuhnZfrOVxlfJ/Ydm
NS7WBBBFd9V4FPyRDPER/QMVl+xyoaMGw0QKnslmq/JvID4FPd0/QD62RAsTntXI
ATa+CS6MjloKFgRaGnKAAFPsrEeGjb2JgMOpIfbdx4KT3WkspsK3KPwFPoYza4ih
4eT2HwhcUs4wo7X/XQd+CZjttoLsSyCk5tCmOGU6xLaE1s08R6sz9mM=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDZzCCAk+gAwIBAgIQNO7aLfykR4pE94tcRe0vyDANBgkqhkiG9w0BAQUFADBG
K73RIKZaDkBOuUlRSIfgfovUFJrdwGtMWo3m4dpN7csQAjK/uixfJDVRG0nXk9pq
GXaS5/YCv5B4q4T+j5pa2f+a61ygjN1YQRoZf2CHLe7Zq89Xv90nhPM4foWdNNkr <-----Intermediate Certificate
/Esf1E6fnrItsXpIchQOmvQViis12YyUvwko2aidjVm9sML0ANiLJZSoQ9Zs/WGC
TLqwbQm6tNyFB8c=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIDZzCCAk+gAwIBAgIQNO7aLfykR4pE94tcRe0vyDANBgkqhkiG9w0BAQUFADBG
K73RIKZaDkBOuUlRSIfgfovUFJrdwGtMWo3m4dpN7csQAjK/uixfJDVRG0nXk9pq
GXaS5/YCv5B4q4T+j5pa2f+a61ygjN1YQRoZf2CHLe7Zq89Xv90nhPM4foWdNNkr <-----Root Certificate
/Esf1E6fnrItsXpIchQOmvQViis12YyUvwko2aidjVm9sML0ANiLJZSoQ9Zs/WGC
TLqwbQm6tNyFB8c=
-----END CERTIFICATE-----

Die Datei machine_name_ssl.cer wird im Zertifikats Manager als Machine SSL Zertifikat angegeben. Laut VMware Doku soll da also die komplette Chain rein, wenn eine Intermediate CA eingesetzt wird. Dies scheint aber so nicht zu stimmen. Lässt man die Chain in dieser Datei weg und belässt darin nur das Machine SSL Zertifikat, läuft der Zertifikats Manager problemlos durch und auch die 3rd Party Tools können sich wieder zur VCSA verbinden…

2018/09/04 12:42 · Daniel Graf · 0 Kommentare
blog.txt · Zuletzt geändert: 2016/04/14 11:30 von Daniel Graf