vm

From the DOS/Windows95 perspective, memory management
is one of the strong points of Nintendo cartridges.
- terry@lambert.org

7.3.2024

Qemu logoHP-UX unter QEMU auf Rocky Linux unter VMware austesten

Warum einfach, wenn's auch komplex geht: irgendwo hab' ich vor einiger Zeit zufällig darüber gelesen, HP-UX unter QEMU in der HPPA Emulation zum Laufen zu bringen. Gesagt, getan: zuerst ein Rocky Linux 9 (einer der potentiellen Nachfolger von CentOS) unter VMware installiert, jede Menge Schrott nachinstalliert und anschliessend QEMU aus den Sourcen für PA-RISC kompilieren. Es brauchte einige Anläufe und Nachbesserungen um das Ding dann zum Fliegen zu bringen.

Nachdem das erledigt war, folgte der Kampf mit der QEMU commandline . . . . - aber - es hat sich gelohnt, ein 32bit HP-UX 10.20 läuft bislang klaglos (und auch entgegen meinen Erwartungen recht zügig). Meine commandline sieht so aus:

qemu-system-hppa -boot d -serial telnet:127.0.0.1:4441,server -drive file=hpux.img,format=raw -serial mon:stdio -nographic -m 512 -d nochain -bios hppa-firmware.img -cdrom mcoe.1_5.iso

Damit wird qemu gestartet und von einem anderen Terminal aus dann: "telnet 127.0.0.1 4441" und los gehts.

Das 64bit HPUX wollte nicht so recht, eine Mail brachte Klarheit, es ist noch nicht so weit, es sind noch Bugs in der 64bit Emulation. Nun ja, ein paar Links möchte ich hier für den nächsten Versuch aufbewahren:

Der Artikel "Running HP-UX 11.11 on the Apple M1" beschreibt, wie der Autor HPUX unter QEMU auf einem ARM Mac zum rennen bekommt. Dann beschreibt mit "Running HP-UX 11.11 on qemu-system-hppa" jemand, wie er HPUX unter QEMU auf einem Debian Rechner installiert hat. Beide Artikel sind schon ein paar Jahre alt, etwas Aktuelleres habe ich nicht gefunden. Etwas neuer und genereller ist "QEMU for PA-RISC" auf kernel.org, aber auch nicht richtig hilfreich.

Um an ISO's für HP9000/700er Maschinen zu kommen (ich habe hier nur 800er CD's) habe ich dies hier http://tenox.pdp-11.ru/os/hpux/OS/11.11/ benutzt und fühlte mich nicht richtig wohl dabei . . .

 

11.02.2024

ESXi booten via SD-Karte oder USB-Stick (und wie man sich dabei toll in den Fuß schiessen kann)

Böses Foul: bisher benutze ich SD Karten bzw. USB Sticks um die ESXi Boot-"Platte" dort unterzubringen, die (HPE) Server haben dafür extra USB Buchsen bzw. SD Kartenträger auf den Mainboards. Früher waren es 8GB seit einigen Jahren 16GB - kleinere Karten gibts nicht mehr . . . Nun ja, ich hatte vor einigen Wochen ganz seltsame Effekte, erst im vCenter, dann in einem ESXi, alles unter vSphere 7.x. Ich habe dann erst angefangen, Images von den Karten zu ziehen, das schlug fehl. In diesem Zusammenhang bin ich für die dd(1) Option "conf=noerror,sync" sehr dankbar (als ich das noch für dicke 5 1/4" Festplatten benutzte, gab es diese Option noch nicht). Irgendwie hab' ich den ganzen Kram dann gesichert bekommen, habe die "Recovery" Option beim ESXi Booten zu schätzen gelernt und dann schliesslich herausgefunden, das auf der SD Karte einige Sektoren defekt und nicht mehr lesbar waren. Also frisch ans Werk, 32G Karten besorgt - kleinere Karten gibts nicht mehr - und das Ganze wieder aufgesetzt. Wunderschön. Solange, bis auf der Konsole irgendwelche Ausschriften von "/bootblock not found" oder so auftauchten (siehe auch u.a. https://kb.vmware.com/s/article/83963). Das Ende vom Lied war, das SD Karten bzw. USB Sticks von VMware 7.x bzw. 8.x nicht mehr supported werden, und zwar aus den verschiedensten Gründen:

SD card/USB boot device revised guidance (85685) - https://kb.vmware.com/s/article/85685

Übergangsweise hab' ich mir dann (in Ermangelung einer SATA bzw. NVME Schnittstelle auf dem Mainboard) nach viel Suchen und Lesen USB-NVME Adapter höherwertigerer Bauart samt 128G NVME Karten besorgt und damit erst 7.x wieder hergestellt und dann auf 8.x upgegradet. Keine Fehler mehr, keine Konsolen Meldungen, läuft wunderbar.

Was mir in diesem Zusammenhang noch geholfen hat:

Im Übrigen benutze ich nicht die dort angegebenen Befehle, um das ESXi zu sichern und zu restoren, sondern das ESXi Programm /bin/firmwareConfig.py, das für meine Zwecke ganz hervorragend geeignet ist und tadellos funktioniert.

Nachtrag 16.2.2024: In einem ML350G10 hängte sich der USB/NVME immer wieder ab und verlor die Konnektivität, so das ich den NVME Steifen auf eine PCIe Karte montiert habe und jetzt davon boote. Hoffentlich ist jetzt Ruhe. Im anderen Cluster Host mit SuperMicro Board von TK läuft das aber einwandfrei. Seltsam.

Nachtrag 12.3.2024: um die ESXi Konfiguration regelmässig zu sichern, gibt es folgendes script:

#!/bin/sh
HOSTNAME=`hostname -s`
BAKDIR=/vmfs/volumes/log/ESXi-Backup
DATE=`date -Idate`
cd /bin
./firmwareConfig.py --backup $BAKDIR
cd $BAKDIR
mv configBundle-$HOSTNAME.core.m-bit.net.tgz configBundle-$DATE-$HOSTNAME.core.m-bit.net.tgz
find . -name configBundle-\*-$HOSTNAME.core.m-bit.net.tgz -mtime +5 -exec rm {} \;

Das script wird von einem Eintrag in der crontab (/var/spool/cron/crontab/roo) aufgerufen und ausgeführt. Soweit gut. Nach einem Neustart des Hosts ist der crontab Eintrag weg! Also noch ein Eintrag in /etc/rc.local.d/local.sh:

/bin/kill $(cat /var/run/crond.pid)
/bin/echo '17 2 * * * /vmfs/volumes/log/ESXi-Backup/esxi-backup.sh > /vmfs/volumes/log/ESXi-Backup/vss02-logfile 2>&1' >> /var/spool/cron/crontabs/root
/bin/crond

Danach alles testen und wenn es läuft, dann einmal "auto-backup.sh" ausführen, so das /etc/rc.local.d/local.sh gesichert wird und beim nächsten Reboot wieder da ist, wo es war.

 

12.9.2023

HP PA-RISC Emulatorrp2470

Vor einiger Zeit habe ich einen Dongle bekommen, der es erlaubt, einen "Charon-PAR PA-RISC Emulator" zu installieren und zu betreiben. Der Emulator emuliert eine komplette HPUX (bzw. MPE/ix) Maschinen-Hardware, so das es möglich wird, darauf HPUX zu installieren und zu betreiben. Ich war zuerst ein bisschen skeptisch was die Vollständigkeit der Emulation angeht und was die Geschwindigkeit angeht - bin aber sehr angenehm überrascht worden.

Mein Setup ist ein VMware vSphere Cluster, auf dem ich ein CentOS 8 Stream installiert hab'. Auf dem CentOS wiederum wird der Charon Emulator installiert - zusammen mit ein paar weiteren Kleinigkeiten, einem Linux Toolkit und einer HP Terminal Emulation. Beim Konfigurieren ist schon ein bisschen (HP-) Erfahrung nötig, aber die Jungs wissen offensichtlich Unix Schönheiten zu schätzen und zu nutzen. Auf jeden Fall ging das ohne grössere Probleme vonstatten, am Ende hatte man einen PDC Prompt nach dem (virtuellen) Einschalten.

Übungstechnisch habe ich dann einen Ignite-UX Server dort installiert und aufgesetzt, auf den ich anschliessend meine HP9000 / A500/ rp2470 per Ignite gesichert habe und diese wiederum habe ich dann in eine emulierte Maschine per Ignite-Server geklont (booten von einer (virtuellen) HP-UX FOS DVD und dann per Ignite Server installieren auswählen, der PDC kann leider noch kein lan.i.p.a.d boot). Lief alles smooth und ohne Probleme. Ein wirklich schönes Stückchen Software, sehr empfehlenswert.

 

14.7.2023

HPE P408i

ESXi und HPE Smart Storage Administrator

Wenn mensch VMware ESXi auf HPE Proliant Servern installiert und dafür ein VMware ESXi OEM Image für HPE verwendet, landen automatisch die Verwaltungstools für die HPE Smart Array Controller mit auf dem ESXi Server.

Das ist ungeheuer praktisch in einigen Situationen, weil man dann im laufenden Betrieb z.B. neue Festplatten einstecken und neue Arrays konfigurieren kann, die anschliessend im ESXi bzw. im vCenter verfügbar gemacht werden können - alles im laufenden Betrieb.

Eine der vielen Seiten, wo die Möglichkeiten in ganz kurzer Kürze beschrieben ist, ist "Manage HPE Smart Array in VMware ESXi 6.7", das funktioniert nicht nur unter 6.x sondern auch unter ESXi Version 7 und Version 8.

Dokumentation von HP gibts hier: HPE Smart Storage AdministratorUser Guide

 

30.6.2023

Von Hyper-V nach VMware und (hoffentlich nicht) zurück

Um virtuelle Maschinen zu konvertieren habe ich bisher entweder den VMware vCenter Converter Standalone benutzt oder in speziellen Situationen auch das Open Virtualization Format Tool (ovftool) per commandline. Beide sind etwas sperrig zu benutzen aber insbesondere das ovftool kann so ziemlich alles.

Mit Hyper-V habe ich das eine oder andere Tänzchen getanzt, Micro$oft Software eben. Und als es mal wieder soweit war, einen Hyper-V durch einen VMware Server abzulösen, habe ich mich dran erinnert, das mir der schon mal den Arsch gerettet hat, habe ich den mal wieder benutzt und bin sehr zufrieden damit. Und es ist auch noch freie Software. Dankeschön dafür!

 

6.4.2023

Veeam Backup & Recovery und vCenter Snapshots

Ein Problem, das mich schon lange nervt sind nicht gelöschte Snapshots von Veeam Backup & Recovery. Normalerweise mache ich eine wöchentliche Vollsicherung via Veeam B & R und danach inkrementelle Backups. Eine Unschönheit ist dabei, das Veeam offenbar von Zeit zu Zeit beim vCenter "vergisst", den Snapshot zu löschen (oder vCenter sich weigert zu löschen) - und wenn diese Kombination damit erstmal anfängt, hört es auch nicht wieder auf, so das es Situationen gibt, in denen das vCenter nur noch EXTREM träge reagiert, weil es da 10 bis 15 alte Veeam Snapshots gibt. Um die Snapshots zu entdecken, muss Mensch sich erstmal einloggen und dann nachschauen. Generve. Ein Script muss her, das soetwas meldet!

Nun gibt es bei VMware das perl SDK, das mittlerweile nicht mehr unterstützt wird und offenbar durch Powershell abgelöst werden soll. Powershell, na ja.

Unter FreeBSD gibt es da den "vmware-vsphere-cli" Port: dafür lädt man sich das VMware-vSphere-Perl-SDK-6.7.0-8156551.i386.tar.gz von VMware herunter (gibts immer noch) und lässt sich den Port bauen und installieren. Danach kann man dann ein solches Kommando absetzen:

snapshotmanager.pl --url https://10.10.10.10:443/sdk/webService --username administrator@host.furz.net --password donaldistbloed --vmname "vCenter Server" --operation list

und bekommt dann z.B. diese Ausgabe:

Snapshots for Virtual Machine vCenter Server under host 10.10.11.11

Name                                           Date             State Quiesced
  VM-Snapshot 6.4.2023, 14:04:00                 2023-04-06T12:04 poweredOn N

die sich anschliessend sehr schön in einem Shell Script verwenden lässt, um bei Bedarf Mail an den netten Admin zu schicken.

 

12.5.2022

Festplatte lässt sich nicht unmounten unter ESXi 7.0

 

1) check ob die scratch location auf der Platte liegt (KB1033696):

in der ESXi Web-Oberfläche unter Host->Verwalten->System->Erweiterte Einstellungen suchen nach ScratchConfig.ConfiguredScratchLocation und ggf. ändern. Nach einer Änderung ist ein Reboot nötig.

2) nachgucken ob der coredump auf der Platte liegt, entweder mit (KB2077516):

esxcli system coredump file list

oder mit (KB2004299):

esxcli system coredump partition list

Komplett abschalten lässt sich der Mechanismus mit (siehe KB74537): 

esxcli system settings kernel set -s autoCreateDumpFile -v FALSE

3) welcher Prozess hat noch offene Files auf dem Filesystem:

UUID herausfinden:

esxcli storage filesystem list

Prozess herausfinden

lsof | grep <UUID>

 

13.2.2022

Debugging VMware ESXi 6.7 / 7.0 mit NFS Storage

Seit geraumer Zeit hatte ich Probleme mit meiner VMware / vSphere Installation: immer wieder begab sich das Ganze in einen APD Zustand, der immerhin solange anhielt, das sich ein paar meiner FreeBSD Gäste neu starteten, weil sie nicht mehr auf ihre Disk Drives zugreifen konnten. Die WIndows Server liess das völlig kalt.

Das Setup ist einfach, jeweils zwei per Teaming redundant an den Host angeschlossene 1GB Ethernet Ports (HCL supported), per LACP statisch im Switch konfigurierte Trunks und von dort an ein Synology NAS, hier per dnamischem LACP Trunk konfiguriert. Sparates Subnetz dafür, kein Zugang nach aussen. Lief jahrelang ohne Probleme, irgendwo zwischen 6.5 und 6.7 fing das an, Probleme zu machen.

Es passierte eigentlich ohne vorherige Fehler irgendwelcher Art und so tauschte ich nach und nach alle Hardware aus: zuerst die Kabel, dann die Netzwerkkarte, dann den Switch. Debuggen, tracen, wiresharken und was weiss ich nach alles. Völlig ohne Erfolg. Guugeln brachte nur Hinweise, das ich offenbar nicht der einzige mit diesen Problemen war/bin, aber Lösungen gleich Null. Ein Schwenk auf einen alten PC mit ein paar Platten und darauf installiertem TrueNAS brachte Ruhe aber ich wollte die Synology nicht wegschmeissen. Also habe ich mich über die ESXi Logs hergemacht.

So fing es an:

2022-01-14T10:13:43.289Z cpu5:2097943)WARNING: NFS: 5080: NFS volume nfs01_syn average I/O latency 1631451(us) has exceeded threshold 10000(us) for last 10 minutes
2022-01-14T10:13:43.574Z cpu15:2097943)NFS: 4979: NFS volume nfs01_syn performance has improved. I/O latency reduced from 118057(us) to 23241(us).
2022-01-14T10:13:45.970Z cpu19:2097943)WARNING: NFS: 5023: NFS volume nfs01_syn performance has deteriorated. I/O latency increased from average value of 2762(us) to 40928(us).
2022-01-14T10:14:12.569Z cpu0:2098903)SunRPC: 3291: Synchronous RPC cancel for client 0x430bf6201a00 IP 1.2.3.4.8.1 proc 1 xid 0x5b1fead0 attempt 1 of 3
2022-01-14T10:14:22.569Z cpu1:2098903)SunRPC: 3291: Synchronous RPC cancel for client 0x430bf6201a00 IP 1.2.3.4.8.1 proc 1 xid 0x5b1fead0 attempt 2 of 3
2022-01-14T10:14:24.569Z cpu14:2105016)SunRPC: 3291: Synchronous RPC cancel for client 0x430bf6201a00 IP 1.2.3.4.8.1 proc 1 xid 0x5b1feba3 attempt 1 of 3
2022-01-14T10:14:25.569Z cpu3:2097943)StorageApdHandler: 1191: APD start for 0x4317ac608d70 [81223b57-7a3f251f]
2022-01-14T10:14:25.569Z cpu15:2097357)StorageApdHandler: 408: APD start event for 0x4317ac608d70 [81223b57-7a3f251f]
2022-01-14T10:14:25.569Z cpu15:2097357)StorageApdHandlerEv: 110: Device or filesystem with identifier [81223b57-7a3f251f] has entered the All Paths Down state.

Und so hörte es wieder auf:

2022-01-14T10:14:53.990Z cpu5:2097943)WARNING: NFS: 5023: NFS volume nfs01_syn performance has deteriorated. I/O latency increased from average value of 2850(us) to 524271(us).
2022-01-14T10:14:54.063Z cpu10:2097943)NFS: 4979: NFS volume nfs01_syn performance has improved. I/O latency reduced from 524271(us) to 101609(us).
2022-01-14T10:14:56.167Z cpu17:2097943)StorageApdHandler: 1304: APD exit for 0x4317ac608d70 [81223b57-7a3f251f]
2022-01-14T10:14:56.167Z cpu15:2097357)StorageApdHandler: 501: APD exit event for 0x4317ac608d70 [81223b57-7a3f251f, 0]
2022-01-14T10:14:56.167Z cpu15:2097357)StorageApdHandlerEv: 117: Device or filesystem with identifier [81223b57-7a3f251f] has exited the All Paths Down state.
2022-01-14T10:14:56.588Z cpu9:2097943)NFS: 4979: NFS volume nfs01_syn performance has improved. I/O latency reduced from 101609(us) to 19764(us).

Ein bisschen ins Blaue geguugelte Ausdrücke förderten dann drei hilfreiche Dinge zu Tage:

Letztlich brachte dann auch das letzte Paper oben die größte Hilfe: auf allen beteiligten Hosts 

esxcli system settings advanced set -o "/SunRPC/SetNoDelayedAck" -i 1

ausführen und danach den Host neu starten. Die Frequenz der APD's sank von etwa zwei bis dreimal pro Tag auf ein bis zweimal pro Monat, eine echte Erleichterung. Aber, ich hatte mal eine völlig störungsfrei laufende Umgebung und so hätte ich es auch gerne wieder gehabt. Alle weiteren Versuche, die APD's komplett zu eliminieren schlugen fehl und so entschloss ich mich, komplett von NFS auf iSCSI umzustellen. Seitdem gibt es gar keine Probleme mehr.

Es scheint mit einer Überlastung der Synology zusammenzuhängen: unter NFS gab's Load Averages bis zu 30, 40 und 50 wenn auf der auf der Kiste was los war (Backup etc), unter iSCSI geht das jetzt selten über 5 oder 6.

5.1.2022

VMware ESXi Netzwerk Debugging Hilfen:

esxcli network ip neighbor list                    ist das VMware Equivalent zu arp -an unter Unix

esxcfg-nics -l                                              zeigt die verfügbaren physischen Ethernet Interfaces (vmnicX)

esxcfg-vmknic -l                                         zeigt die verfügbaren Kernel Interfaces (vmkX) samt ihrer Eigenschaften an

esxcli network ip interface list                    wie ifconfig für die Kernel Interfaces

esxcli network ip connection list                 wie netstat -an

 

 

UPDATE zu: VMware Remote Console unter MAC OS direkt ohne Umweg über vCenter aufrufen    (August 2018)

Mit Mac OS 10.13 funktioniert das Ganze (unten beschrieben) nicht mehr. .webloc - Files werden jetzt ausschliesslich von Safari aufgerufen und dieser Fakt ist offenbar nicht mehr zu ändern.

Nach langem Suchen ist die Lösung ganz einfach: die Endung .webloc wird umbenannt in .inetloc und schon funktioniert alles wieder - offenbar sogar schneller, da der initiale Browser Aufruf nicht mehr erfolgt, sondern die VMware Remote Console direkt aufgerufen wird.

 

VMware Remote Console unter MAC OS direkt ohne Umweg über vCenter aufrufen    (Februar 2017)

Es kam dann irgendwann der dringende Wunsch auf, eine VMware Remote Console ohne den Umweg übers Klicken im vCenter benutzen zu können. Das Ganze auf einem Mac, und am liebsten per Draufklicken. Also, man lege eine Datei (bei mir auf dem Desktop) mit folgendem Inhalt an:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>URL</key>
    <string>vmrc://@<IP Adresse vCenter Server>:443/?moid=<MOID der VM></string>
</dict>
</plist>

Die Datei bekommt die Datei-Endung ".webloc" also z.B. "console-srv42.webloc".

In der Datei ersetze man den Platzhalter "<IP Adresse vCenter Server>" mit der IP Adresse oder mit dem Namen des vCenter Servers.

Der Platzhalter "<MOID der VM>" - die Managed Object Reference ID - erhält man am einfachsten in der vCenter Appliance, wenn man unter "VM's und Vorlagen" die einzelnen VM's anklickt, dann erhält man in der Kopfzeile des Browsers die dazugehörige URL und ganz am Ende der URL finden man eine Zeichenfolge "vm-xxx". Dabei ist "xxx" eine - bei mir - ein- bis dreistellige Ziffernfolge und der resultierende String (also z.B. "vm-42") ist die MOID der jeweiligen VM, die eine Virtuelle Maschine eindeutig identifiziert.

Diese Datei auf dem Desktop ist dann klickbar und öffnet nach anklicken (das erste Mal wird noch der Benutzer und das Passwort des vCenters abgefragt, wer hier das Passwort im Schlüsselbund des Mac's sichern möchte, wird danach nicht mehr gefragt) ohne weiteres zutun dann eine VMware Konsole auf dem Schirm.

 

 

 

Bildschirm Auflösung für VMware Gast Mac OS X unter ESXi einstellen     (August 2016)

Wenn mensch Mac OS X als Gastbetriebssystem unter ESXi installiert, ist die Bildschirmauflösung in der VMware Remote Konsole fest auf 1024x768 eingestellt, was meist nicht ausreichend ist. Nach Installation der VMware Tools findet sich auf dem Mac mit 

/Library/Application Support/VMware Tools/vmware-resolutionSet

ein Programm, womit sich die gewünschte Auflösung persistent einstellen lässt.

 

 

 

vib per commandline auf einem ESXi installieren     (August 2016)

- SSH Login freigeben

- per SSH auf dem ESXi einloggen

- in das Verzeichnis wechseln, in dem das vib zu finden ist und dann:

esxcli software vib install  -v $PWD/name-des-zu-installierenden-vibs.vib

Wenn die Meldung:

'Could not find a trusted signer.'

kommt, dann kommt man durch anhängen eines "--no-sig-check" ggf. weiter.

 

 

 

SD-Card oder USB-Stick basierender Host in's vCenter hinzufügen  (Juni 2016)

Wenn ESXi auf einer SD Karte installiert wurde, kommt nach dem Hinzufügen in's vCenter folgende Meldung:

Systemprotokolle auf dem Host <Name oder IP-Adresse> werden in einem nicht beständigen Speicher gespeichert.

Abhilfe bringt u.A. das Speichern der Protokolle auf einem Rechner, auf dem Syslog läuft und wo der Syslog Port freigegeben ist. In der vCenter Host-Ansicht unter Verwalten -> Einstellungen -> Erweiterte Systemeinstellungen den Wert Syslog.global.logHost mit einer URL füllen, die auf den Syslog-Rechner zeigt. Syntax ist "Protokoll://Rechner:Port" also z.B. udp://192.168.255.13:514

 

 

 

ESXi 6.0.0 auf Update 2 bringen  (Mai 2016)

Und dann wollte ich noch meinen etwas betagten ESXi Server auf den neuesten Stand bringen. Dazu fand ich diese Seite, die einen brauchbaren Weg beschreibt, der allerdings bei mir nicht funktionierte: erstens löst mein interner Nameserver keine externen Namen auf und zweitens wird intern ein http-Proxy benutzt.

Es ging schliesslich so:

1. ESXi per GUI in den Wartungsmodus bringen

2. ESXi Firewall aufmachen

esxcli network firewall ruleset set -e true -r httpClient

3. DNS Server aufmachen (in der named.conf für diese IP rekursive Abfragen konfigurieren) und dem ESXi bekannt machen:

esxcli network ip dns server add -s=192.168.42.42

Selbst bei der Verwendung von IP Adressen und einem Proxy gings nicht, erst ein Nameserver brachte abhilfe ...

4. Patches holen und applizieren

esxcli software profile update -p ESXi-6.0.0-20160302001-standard -d http://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml --proxy=http://192.168.42.142:8080

5. ESXi Firewall wieder zumachen

esxcli network firewall ruleset set -e false -r httpClient

6. Reboot ESXi

7. Wartungsmodus via GUI beenden

Und siehe da, wirklich, man kann den ESXi Server jetzt unter https://<esxi-server>/ui wunderschön über den Browser bedienen und braucht den vSphere Client nicht mehr (bzw. nur noch selten, alles geht per Browser nicht).

 

ESXi 6 virtuelle Maschinen klonen  (Mai 2016)

Unter dem freien VMware ESXi gibt es keine Option im vSphere Client, um eine Maschine zu klonen. Am simplesten ist es (bei freigegebenem ssh Zugriff auf das ESX) auf der Kommandozeile die virtuelle Festplatte zu kopieren:

cd /vmfs/volumes
vmkfstools -i FreeBSD-10.3-TEMPLATE/FreeBSD-10.3-TEMPLATE_1.vmdk FreeBSD-10.3-STABLE/FreeBSD-10.3-STABLE_1.vmdk -d thin

( Doku zu vmkfstools gibts hier )

... und dann mit dem vSphere Client  eine neue virtuelle Maschine zu erzeugen, die die eben kopierte Datei als Festplatte benutzt und fertig.