Anpassungen der VM
SSH Login für den User root erlauben
Die Arbeit an der Konsole ist nicht komfortabel, aber noch können wir als root keine SSH Sitzung öffnen. Das werden wir als erstes ändern.
cd /etc/ssh
Wir müssen die Datei sshd_config anpassen. Der einzige hierfür zur Verfügung stehende Editor ist vi (sorry, kein nano).
vi sshd_config
Mit Taste [i] gelangen wir in den Einfügemodus. Mit den Pfeiltasten können wir bis fast zum Ende der Datei vorrücken. Alternativ kann man auch Taste [G] drücken, um zum Ende der Datei zu springen und dann mit [i] in den Einfügemodus wechseln. Wir müssen die Einstellung PermitRootLogin von “no” auf “yes” setzen.
In Produktivumgebungen ist dies nicht empfohlen, aber wir verwenden hier ohnehin ein System ohne offiziellen Support. 😉
Zum Speichern der Änderungen drücken wir nacheinander die Tasten [Esc] + [:] + [wq] + [Enter]
Um die Einstellungen zu überprüfen, geben wir folgenden Befehl ein.
cat sshd_conf
Jetzt können wir die Konsole mit exit verlassen und schließen. Es ist nun möglich, eine SSH Verbindung als root öffnen.
Installation der open-vm-tools
Photon OS hat einen eigenen Paketmanager namens Tiny Dandified Yum (tdnf).
tdnf install open-vm-tools
root@k3node1 [ ~ ]# tdnf install open-vm-tools Refreshing metadata for: 'VMware Photon Extras 4.0 (aarch64)' Refreshing metadata for: 'VMware Photon Linux 4.0 (aarch64)' Refreshing metadata for: 'VMware Photon Linux 4.0 (aarch64) Updates' photon-updates 123 100% Installing: nss aarch64 3.57-1.ph4 photon 1.64M 1717 059 libxml2-devel aarch64 2.9.10-3.ph4 photon 421.22k 4313 33 xmlsec1 aarch64 1.2.30-3.ph4 photon 1014.40k 103 8744 libxslt aarch64 1.1.34-1.ph4 photon 377.39k 3864 52 libxml2 aarch64 2.9.10-3.ph4 photon 7.30M 7657 112 libtirpc aarch64 1.2.6-1.ph4 photon 193.42k 1980 57 libmspack aarch64 0.10.1alpha-1.ph4 photon 71.69k 734 08 libdnet aarch64 1.11-7.ph4 photon 114.07k 1168 07 fuse aarch64 2.9.9-1.ph4 photon 321.09k 3287 98 open-vm-tools aarch64 11.1.5-4.ph4 photon 2.16M 2268 731 Total installed size: 13.56M 14216501 Is this ok [y/N]:
Bestätigung mit Taste [y].
Downloading: nss 733496 100% libxml2-devel 98485 100% xmlsec1 352774 100% libxslt 178792 100% libxml2 1594207 100% libtirpc 102725 100% libmspack 47776 100% libdnet 48576 100% fuse 120301 100% open-vm-tools 823199 100% Testing transaction Running transaction Installing/Updating: libxml2-2.9.10-3.ph4.aarch64 Installing/Updating: libxml2-devel-2.9.10-3.ph4.aarch64 Installing/Updating: libxslt-1.1.34-1.ph4.aarch64 Installing/Updating: fuse-2.9.9-1.ph4.aarch64 Installing/Updating: libdnet-1.11-7.ph4.aarch64 Installing/Updating: libmspack-0.10.1alpha-1.ph4.aarch64 Installing/Updating: libtirpc-1.2.6-1.ph4.aarch64 Installing/Updating: nss-3.57-1.ph4.aarch64 Installing/Updating: xmlsec1-1.2.30-3.ph4.aarch64 Installing/Updating: open-vm-tools-11.1.5-4.ph4.aarch64 Created symlink /etc/systemd/system/vmtoolsd.service.requires/vgauthd.service → /usr/lib/systemd/system/vgauthd.service. Created symlink /etc/systemd/system/multi-user.target.wants/vmtoolsd.service → /usr/lib/systemd/system/vmtoolsd.service. Complete! root@k3node1 [ ~ ]#
Bugfix
Nach dem Reboot der VM werdet Ihr wahrscheinlich einer lästigen Fehlermeldung begegnen.
Unknown ioctl 1976
Die Meldung poppt immer wieder auf – zumindest auf der Konsole. Möglicherweise wird das in einer künftigen Version gefixt. Bis dahin hilft ein schmutziger Hack, um das Problem zu umgehen.
Dazu loggen wir uns als root über SSH ein und erzeugen ein file blacklist.conf.
cd /etc/modprobe.d touch blacklist.conf vi blacklist.conf
Folgende Zeilen müssen dem leeren File zugefügt werden:
blacklist vsock_loopback blacklist vmw_vsock_virtio_transport_common install vsock_loopback /usr/bin/true install vmw_vsock_virtio_transport_common /usr/bin/true
System neu starten und die Meldung ist weg.
Firewall iptables modifizieren
Eine Firewall ist in Produktivumgebungen immer eine gute Idee, jedoch verursacht diese einige Schwierigkeiten bei der Installation von K3s. Ich befolgte daher William Lams Empfehlung, iptables für dieses Projekt zu deaktivieren.
systemctl stop iptables systemctl disable iptables
Damit sind wir mit unserer Basisinstallation am Start. Natürlich könnten wir alle oben aufgeführten Schritte für jede weitere VM wiederholen, es ist jedoch eleganter die Disk zu klonen. Damit sind wir auch schon beim Thema: Klonen ist auf einem Standalone ESXi Host nicht so simpel wie wir es vom vSphere-Client gewohnt sind. Es ist aber auch keine Hexerei. Dazu müssen wir die gerade vorbereitete VM herunterfahren.
Im ersten Schritt bauen wir zwei weitere VMs mit den gleichen Eigenschaften wie oben, jedoch ohne Disk. Standardmäßig wird eine Disk zugefügt. Diese entfernen wir aktiv (vgl. Bild)
Nachdem wir die VMs vorbereitet haben, kopieren wir die Disk der ersten VM in die Verzeichnise der beiden neuen. Das können wir entweder mit dem Hostclient des ESXi on Arm machen, oder auf der SSH Konsole (dazu erst den SSH-Dienst auf dem Host aktivieren).
Im nun folgenden Beispiel kopiere ich das vmdk und das zugehörige Flatfile an den neuen Speicherort und ändere den Namen passend zur Ziel-VM.
cp /vmfs/volumes/pi-Datastore01/k3node-1/k3node-1.vmdk /vmfs/volumes/pi-Datastore01/k3node-2/k3node-2.vmdk cp /vmfs/volumes/pi-Datastore01/k3node-1/k3node-1-flat.vmdk /vmfs/volumes/pi-Datastore01/k3node-2/k3node-2-flat.vmdk
Es ist notwendig, die obigen Codezeilen entsprechend der eigenen VM-Namen und Datenspeicher anzupassen.
Bevor wir das Diskfile einbinden können, müssen wir den Namen des Flatfiles im Deskriptor (VMDK) anpassen. Hier am Beispiel der VM2 gezeigt:
vi /vmfs/volumes/pi-Datastore01/k3node-2/k3node-2.vmdk
Die obigen Schritte müssen analog für VM3 ausgeführt werden. Dann können die kopierten und umbenannten Disks in VM2 und VM3 (k3node-2 bzw. k3node-3) eingebunden werden. Dazu in den Einstellungen der VM eine (bestehende) Disk hinzufügen und die Disk auswählen, die wir zuvor vorbereitet hatten.
Einstellungen der geklonten VM anpassen
Wir sind noch nicht fertig. Noch haben unsere zweite und dritte VM identische Einstellungen (Hostname, IP, etc.) wie die erste VM.
Zur Vermeidung eines IP Konflikts sollten alle VMs ausgeschaltet sein. Startet nun VM2, um im OS die Einstellungen anzupassen. Es ist unter Umständen günstiger, diese Änderungen an der Konsole zu machen, da wir die IP Adresse ändern werden und so den Kontakt auf der SSH Konsole verlieren.
Hostnamen ändern
Der Hostname ist noch identisch mit der ersten VM, da wir die ganze Disk geklont haben.
vi /etc/hostname
Den alten durch den neuen Hostnamen ersetzen.
Netzwerk-Einstellungen ändern
Das gleiche gilt auch für die Netzwerk-Einstellungen.
cd /etc/systemd/network
Im Verzeichnis /etc/systemd/network werdet Ihr wahrscheinlich eine Datei finden, die mit 99- beginnt. Wie z.B. 99-static-en.network.
Editiert die Datei und passt die IP Adresse an (rote Markierung). Knoten2 erhält bei mir die neue Adresse 10.0.10.172.
Einträge in der hosts Datei anpassen
Es ist wichtig, dass auch die hosts Datei unter /etc/hosts an den neuen Hostnamen angepasst wird. Ich hatte das vergessen und damit zunächst unerklärliche Probleme beim K3s Cluster-Beitritt provoziert.
Update der Machine-ID
Dieser Schritt ist wichtig, falls DHCP für die Adressvergabe eingesetzt wird. Ohne neue Machine-ID wird die VM weiterhin die selbe IP Adresse erhalten wie VM1. Bei statischer Adressvergabe ist dieser Schritt optional, aber empfohlen.
echo -n > /etc/machine-id
Bearbeitung abschließen
Die VM neu starten, oder alternativ den Netzwerk Daemon neu starten.
systemctl restart systemd-networkd
Für VM3 müssen wir die gleiche Prozedur ausführen.