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 - Kickstart Installation von ESXi Hosts

Bevor ich jedes Mal aufs neue die Dokumentation wälzen muss, wie eine ESXi Kickstart Installation auszusehen hat, möchte ich dies hier kurz festhalten. Ich werde auf einem Cisco Server mit einem Custom Image (Vmware-ESXi-6.5.0-7967591-Custom-Cisco-6.5.1.3 von My VMware) die Installation mittels KVM und ISO Image vornehmen.

Zu Beginn habe ich das Custom Image mittles WinRAR in einen eigenen Ordner entpackt. Darin habe ich den Ordner KS angelegt, in dem meine Kickstart Dateien liegen, für jeden Server eine eigene Datei (da ja jeder Server einen anderen Hostnamen und eine andere IP Adresse hat…). Hier ein Beispiel der Kickstart Datei für meinen ersten ESXi Host:

# Accept VMware License agreement
accepteula
 
# Set the root password
rootpw SicheresPasswort2018!
 
# Install ESXi on the first disk (Local first, then remote then USB)
install --firstdisk --overwritevmfs
 
# Set network settings
network --bootproto=static --hostname=esxi01--device=vmnic0 --ip=192.168.0.1 --netmask=255.255.255.0 --gateway=192.168.0.254 --nameserver=192.168.0.254
 
# Set the keyboard
keyboard German
 
# reboot the host after installation is completed
reboot
 
# run the following command only on the firstboot
%firstboot --interpreter=busybox
 
# enable & start remote ESXi Shell (SSH)
vim-cmd hostsvc/enable_ssh
vim-cmd hostsvc/start_ssh
 
# enable & start ESXi Shell (TSM)
vim-cmd hostsvc/enable_esx_shell
vim-cmd hostsvc/start_esx_shell
 
# supress ESXi Shell shell warning
esxcli system settings advanced set -o /UserVars/SuppressShellWarning -i 1
 
# Network adapter information
NetName="vmk0"
IPAddress="192.168.0.1"
NetMask="255.255.255.0"
Gateway="192.168.0.254"
DNS01="192.168.0.254"
DNS02="192.168.10.254"
NTP01="${DNS01}"
NTP02="${DNS02}"
VlanID="100"
 
# Hostname and domain settings
HostName="esxi01"
SuffixDNS="lab.home"
FQDN="${HostName}.${SuffixDNS}"
 
# set IP + default route + DNS
esxcli network ip interface ipv4 set --interface-name=vmk0 --ipv4=${IPAddress} --netmask=${NetMask} --type=static --gateway=${Gateway}
esxcli network ip dns server add --server ${DNS01}
esxcli network ip dns server add --server ${DNS02}
 
# Set VLAN ID
esxcli network vswitch standard portgroup set --portgroup-name "Management Network" --vlan-id ${VlanID}
 
# Disable ipv6
esxcli network ip set --ipv6-enabled=0
 
# set suffix and FQDN host configuration
esxcli system hostname set --fqdn=${FQDN}
esxcli network ip dns search add --domain=${SuffixDNS}
 
# NTP Configuration
cat > /etc/ntp.conf << __NTP_CONFIG__
restrict default kod nomodify notrap noquerynopeer
restrict 127.0.0.1
server ${NTP01}
server ${NTP02}
__NTP_CONFIG__
/sbin/chkconfig ntpd on
 
# rename local datastore to something more meaningful
vim-cmd hostsvc/datastore/rename datastore1 "${HostName}_datastore"
 
# restart a last time
reboot

Die Dokumentation zu den Parametern findet sich (größtenteils) hier.

Anschließend baue ich aus dem Ordner des entpackten Custom Image mittels ImgBurn wieder ein ISO Image. Beim Erstellen des Image ist zu beachten, dass es bootfähig gemacht werden muss. Dies gelingt mit den folgenden Optionen:

Als Boot Image wird hier die Datei ISOLINUX.BIN angegeben, die sich im entpackten Custom Image Ordner befindet!!

Das nun fertige Image wird dann in der Cisco KVM gemounted und gebootet. Sobald der VMware Boot Loader erscheint, muss schnell <TAB> gedrückt werden, damit der Prompt des Boot Loaders erscheint:

An die bestehende Zeile wird dann nur noch ks=cdrom:/KS/KS1.CFG angehängt:

ACHTUNG: Datei- und Ordnernamen müssen groß geschrieben werden. Ebenso muss die Zahl der Zeichen in Dateinamen beachtet werden. Dies ist auch im VMware KB Artikel KB1026373 - Integrating a Kickstart config file in an ESXi ISO fails to be found during installation noch mal zu lessen.

2018/07/19 15:56 · Daniel Graf · 0 Kommentare

VMware - Certificate from 'TRUSTED ROOTS' expires on ...

Nein! Das ist nicht mein erster Blog Post in englisch :-D Ich fand nur, dass es für den Titel keine bessere Formulierung gab, als direkt die Fehlermeldung (in gekürzter Form) zu verwenden ;-)

Vor noch nicht so langer Zeit habe ich im vCenter Log eines Kunden die folgende Meldung gesehen:

[warn] Certificate 'CN=*.customer.com,O=Customer United,L=Some Location,ST=Some State,C=DE' from 'TRUSTED_ROOTS'
       expires on 2018-06-25 23:59:59.000

„Nun gut, nichts besonderes“ dachte ich mir. Im vCenter also das Menü Certificate Authority geöffnet und die Einträge der Root Certificates kontrollieren… Da war allerdings das gemeldete Zertifikat nicht gelistet!? Nach einem Telefonat mit dem Kunden hat sich herausgestellt, dass er mal versucht hat ein eigenes Zertifikat (von einer eigenen CA) einzuspielen. Dabei ist aber irgendetwas (O-Ton Kunde ;-)) schief gegangen, weshalb auf dem vCenter ein Rollback initiiert wurde. Und offensichtlich ist dabei das Zertifikat im Root Certificates Store hängengeblieben, ohne dass es im vSphere Web Client angezeigt wird.

Über die CLI des vCenters (hier eine vCenter Server Appliance) lässt sich das Problem lösen. Zuerst sollte ein Backup aller Zertifikate in allen Trust Stores erstellt werden:

for _TRUST_STORE in $( /usr/lib/vmware-vmafd/bin/vecs-cli store list ) ; do
  echo "Store name: ${_TRUST_STORE}" >> /tmp/all_certificates
  /usr/lib/vmware-vmafd/bin/vecs-cli entry list --store ${_TRUST_STORE} >> /tmp/all_certificates
done

Über den folgenden Befehl kann man sich alle Zertifikate des Stores Root Certificates anzeigen lassen:

/usr/lib/vmware-vmafd/bin/vecs-cli entry list --store TRUSTED_ROOTS --text

Bei der Ausgabe wird zu jedem Zertifikat auch die Alias ID ausgegeben, ein 40 Zeichen langer alpha-nummerischer String. Über den Zertifikats String lässt sich die dazugehörige Alias ID ermitteln.

Mit dieser Alias ID lässt sich nun das Zertifikat aus dem Store entfernen:

/usr/lib/vmware-vmafd/bin/vecs-cli entry delete --store TRUSTED_ROOTS --alias <Alias ID>

Anschließend kann man sich alle Zertifikate des Stores noch mal ansehen. Die Meldung im vSphere Web Client muss man natürlich noch manuell löschen.

2018/07/06 15:49 · Daniel Graf · 0 Kommentare

VMware - Einstieg in die vSphere REST API

Ich weiß eigentlich gar nicht warum, aber irgendwie ist die vSphere REST API an mir vorbeigerauscht 8-O Für mich (und vielleicht auch für manch anderen) möchte ich hier ein paar Befehle dokumentieren :-)

Die beschreibung zur API findet sich übrigens auch in jedem vCenter ab Version 6.5 unter https://vcenter.lab/apiexplorer/ (die Adresse müsst ihr natürlich anpassen ;-)).

Meine Code Beispiele schreibe ich in Bash. Zudem arbeite ich mit den folgenden Variablen…

_VCENTER_HOSTNAME="vcenter.lab"
_VCENTER_USERNAME="administrator@vsphere.local"
_VCENTER_PASSWORD="VMware1!"
 
_CURL_DEFAULTS="--header 'Accept: application/json' --insecure --silent"

Zudem nutze ich noch das Tool jq, um mir den JSON Output in einem Menschen lesbaren Format anzeigen zu lassen.

Auch bei der API gibt es eine Anmeldung. Die Daten sendet man an das vCenter und als Response gibt es einen Session Token, der dann bei den API Requests zur Authentifizierung mit angegeben wird:

_SESSION_TOKEN=$( curl -X POST \
                    ${_CURL_DEFAULTS} \
                    --header "Content-Type: application/json" \
                    --header "vmware-api-session-id: null" \
                    --user   "${_VCENTER_USERNAME}:${_VCENTER_PASSWORD}" \
                    "https://${_VCENTER_HOSTNAME}/rest/com/vmware/cis/session" | jq .value | tr -d '"' )

Um zu prüfen ob man angemeldet ist, lässt sich die Session vom vCenter abfragen:

curl -X POST \
  ${_CURL_DEFAULTS} \
  --header "Accept: application/json" \
  --header "vmware-api-session-id: ${_SESSION_TOKEN}" \
  "https://${_VCENTER_HOSTNAME}/rest/com/vmware/cis/session?~action=get" | jq

Ist man erfolgreich am vCenter authentifiziert, sieht der JSON Response so aus:

{
  "value": {
    "created_time": "2018-07-06T12:10:37.990Z",
    "last_accessed_time": "2018-07-06T12:10:38.560Z",
    "user": "Administrator@VSPHERE.LOCAL"
  }
}

Ist man hingegen nicht (mehr) am vCenter angemeldet:

{
  "type": "com.vmware.vapi.std.errors.unauthenticated",
  "value": {
    "messages": [
      {
        "args": [],
        "default_message": "Authentication required.",
        "id": "com.vmware.vapi.endpoint.method.authentication.required"
      }
    ]
  }
}

Was alles abgefragt, bzw. auch verändert werden kann, findet man in der Doku der vSphere REST API. Ich möchte hier nur ein paar Beispiele bringen…

Mit folgenden Befehl lassen sich alle Datastores ausgeben:

curl -X GET \
     ${_CURL_DEFAULTS} \
     -H "vmware-api-session-id: ${_SESSION_TOKEN}" \
     "https://${_VCENTER_HOSTNAME}/rest/vcenter/datastore" | jq

Möchte man nur die VMFS Datastores gelistet bekommen, hängt man an die URL noch einen Filter für den Type an (?filter.types=VMFS):

curl -X GET \
     ${_CURL_DEFAULTS} \
     -H "vmware-api-session-id: ${_SESSION_TOKEN}" \
     "https://${_VCENTER_HOSTNAME}/rest/vcenter/datastore?filter.types=VMFS" | jq

Nach getaner Arbeit sollte man sich von der API auch wieder abmelden. Dazu wird der Session Token im vCenter gelöscht:

curl -X DELETE \
     ${_CURL_DEFAULTS} \
     --header "vmware-api-session-id: ${_SESSION_TOKEN}" \
     "https://${_VCENTER_HOSTNAME}/rest/com/vmware/cis/session"
2018/07/06 14:12 · Daniel Graf · 0 Kommentare

VMware - vCenter Zertifikat mit mehreren Domain-Namen

Für einen Kunden sollte ich zuletzt auf seiner vCenter Server Appliance das SSL Zertifikat gegen ein eigenes Zertifikat mit mehreren Domain-Namen austauschen, damit im Browser keine SSL Warnung mehr erscheint 8-O Beim Kunden kommt eine eigene CA zum Einsatz, die vCSA soll allerdings keine eigenen Zertifikate ausstellen. Für die Einrichtung bin ich auf folgende Links gestoßen:

Wenn mehrere Domains in einem Zertifikat gelistet werden sollen, muss auch der Primary Network Identifier (PNID) des vCenters im Zertifikat aufgenommen werden, andernfalls erhält man folgende Meldung beim importieren der Zertiifkate:

New MACHINE_SSL_CERT does not contain PNID in the SAN field

Die PNID lässt auf der vCSA mit folgendem Befehl abfragen:

/usr/lib/vmware-vmafd/bin/vmafd-cli get-pnid --server-name localhost
2018/06/26 08:33 · Daniel Graf · 0 Kommentare

VMware - Upgrade-Skript im Update Manager schlägt fehl

Bei einem Kunden habe ich zuletzt einen vSphere Cluster die ESXi Hosts in Version 6.5 auf 6.5U1 aktulisieren wollen. Das Upgrade sollte über den Update Manager der VCSA erfolgen. Bei allen Hosts habe ich wieder und wieder die Meldung bekommen, dass das Upgrade-Skript auf dem ESXi Host nicht ausgeführt werden konnte:

Im Log /scratch/log/esxupdate.log waren auch falsch kodierte Einträge zu sehen, mir fehlen hier nur grad die Beispiele der Einträge :-/

Wie sich herausstellte, gab es in der /etc/passwd einen Eintrag für einen Nutzer, bei dem im Kommentar-Feld ein Umlaut stand. Nachdem ich den Umlaut ersetzt habe und die Prüfung der verfügbaren Upgrades erneut gestartet habe, erschien die Meldung nicht mehr :-)

2018/06/10 13:47 · Daniel Graf · 0 Kommentare
blog.txt · Zuletzt geändert: 2016/04/14 13:30 von Daniel Graf