ESXi (6.5) - usage compendium for Road Warriors

Tags: #<Tag:0x00007f5337e81048> #<Tag:0x00007f5337e80eb8> #<Tag:0x00007f5337e80c38> #<Tag:0x00007f5337e80aa8> #<Tag:0x00007f5337e808f0> #<Tag:0x00007f5337e80670>


ESXi? Aren't you the KVM guy?

Yes, I am the KVM guy as well.


Introduction: what, why, how?

So what’s the big deal you ask?

First of all this article concerns itself with a 1 node ESXi, and not with a vSphere virtualization farm. You can get a free ESXi license from VMware. Some folks say the features are cut so that ESXi is useless, but that’s not exactly true.
Secondly I set this up to learn. Don’t do this for any other reason!
And thirdly it works great, and this experiment was a success.

Here is what ESXi 6.5 does for me:

  • good web UI (the new Embedded Host Client) for ESXi 6.5 is included nowadays
    • it has got Console and GUI access via HTML5 / wss:// / web “VNC” (webmks). This is a killer feature. And this does not need vSphere.
    • I have used libvirt a lot, with virt-manager. But virt-manager needs a Linux Desktop.
    • I took a look at Proxmox. - Doesn’t convince me.
  • networking: ESXi vSwitch seems to be a decent networking component. It’s limited to Layer 2.
    • ESXi won’t do NATing for your guests, but we will get to this
  • monitoring: ESXi has integrated performance monitoring
  • efficiency: ESXi offers options for saving disk space and memory.
  • performance: KVM is a minimal Linux kernel hypervisor. qemu is its userspace layer. ESXi is a bare-metal hypervisor. It’s not a Linux. Vmware’s VMkernel has got a Linux emulation layer, but it’s not a Linux kernel.
    • afaik: KVM will use qemu to create a thread per vCPU. ESXi has it’s own kernel-based scheduling layer between the assigned vCPUs and the CPU sockets. This layer is different, due to things like vNUMA, which decouple vCPUs from the scheduler.

An ESXi (6.5) might have an SSH shell, but it’s not a Bash. Some of the commands resemble GNU coreutils, but that is misleading:

[[email protected]:/bin] uname -a
VMkernel static.kasumi 6.5.0 #1 SMP Release build-4564106 Oct 26 2016 22:24:57 x86_64 x86_64 x86_64 ESXi
[[email protected]:/bin] uptime
 20:18:06 up 02:20:46, load average: 0.01, 0.01, 0.01

[[email protected]:/bin] esxcli network ip connection list
# netcat like output

In short: ESXi is not Linux. GNU is not Unix. Unix is not Linux. You know the drill.

ESXi is not vSphere. vSphere is an orchestration system for ESXi hosts. vMotion is a live-migration system to load-balance between ESXi hosts, which are managed by vSphere. This is one of the enterprise features, but these won’t be accessible from a single-node ESXi.

Goals today: understand ESXi better, use ESXi. Just like Linux KVM with libvirt. Happy hacking in a semi-enterprise setting. The article can indirectly help to answer the question, whether an ESXi is more resource-efficient and versatile in practical scenarios than KVM qemu with libvirt.

I haven’t really looked at Xen or Citrix XenServer, which are probably more comparable. ESXi and XenServer look like mature solutions. XenServer has better licensing options. Some sane people tell me that Hyper-V is surprisingly good. Not today :wink:

Disclaimer: this is a learning article. Do not do this in production. Because security!

Installation steps - from brochure to hack lab

You need to have 2 IPs, at least. In opposite to the popular KVM iptables NAT setups, an ESXi cannot work with just one IP.

  • One IP for the new Web UI, management network etc.
  • One IP of the external network, router-VM. The router-VM can do NATing.

My hack lab here has 2 IPs, which are assigned via DHCP based on the MAC. I can set the MAC address manually for the virtual network adapter of the routing-VM. MAC addresses can be changed. Of course…

Hack server hacks - get to know ESXi vSwitch

Take a look at this:

There is VLAN 0. In VLAN 0 is pfSense, the router-VM. There is the vmk0 as well, with the IP that is blue’ed out. And the virtual uplink is the physical adapter.

This is a hacky setup. Of course you can do a better virtual segregation between management and production traffic if you at least have a dual port NIC. Switches. A colocation rack… an ASA maybe. I know. You do. Let’s shake hands.

The pfSense router-VM gets a route-able IPv4 address from the DHCP via the MAC address of the physical network adapter, which is assigned to the guest. Pretty common.

I created a second virtual switch without an uplink:

As you can see 3 guests are attached to it. pfSense gets 2 virtual network adapters. Why?

Because. “Weil isso” (German). No, because pfSense is the bridge between the 2 virtual switches, and the respective virtual port groups.

This is an anti-pattern! A hack setup, non-enterprise! But this way pfSense can do NATing. It gets a WAN link, and a LAN link. The WAN link will get the route-able IP. The LAN link will be assigned statically, and start a DHCP server. The DHCP server will provision internal IPs to the other guests, such as shell and ubuntu_gnome. And what not.

There is a little chicken-egg egg-chicken problem with this hack. Once you fire up pfSense the web UI listens on something like, an internal IP on the internal vSwitch. You cannot get there from the ESXi SSH shell. Some guides on the internet claim that you can SSH tunnel to this IP, and hop via the ESXi SSH shell. - Not true for ESXi 6.5. Fake news! The network layer is separated, and ESXi has the guest network drivers in the VMkernel afaik.

It doesn’t look like the routes to the guest network get populated to the host networking system.

esxcli network ip route ipv4 list
Network         Netmask          Gateway         Interface  Source
--------------  ---------------  --------------  ---------  ------
default          X.X.X.X  vmk0       DHCP
X.X.X.X         vmk0       MANUAL

esxcli network vm list will list the ports. Maybe if you add the routes… but I haven’t messed with this.

Instead I used a GUI VM with a browser to setup the initial NAT via the pfSense Web UI, also for the shell VM. On the shell VM I installed an OpenSSH server, and NAT-forwarded a port from the pfSense WAN interface to the OpenSSH service on the shell VM. This way I was able to use it as a jump host. This is not elegant… you’d say entrepreneur style… hacky. It works.

Results: this is a super cheap 1 node ESXi, with 2 IPs. It can do NATing with pfSense. It can do switching with vSwitch. And you can get access to GUI guests via the Web UI. And I have an SSH jump host. Awesome.

Reasons for this? Hmmh… does everything need a reason? Yes. And there are good reasons. Always. Because security!

I think it’s more efficient to run Windows guests with an ESXi, because the memory-deduplication and page-compression is advanced, if you chose to enable it.

Enable Sharing Memory Across Virtual Machines on an ESXi 6.5 - memory efficiency

I set the advanced attribute Mem.ShareForceSalting to 0. My choice.

This is for memory deduplication across virtual machines; on my single-node lab ESXi. Vmware calls it “inter-virtual machine transparent page sharing”. It means if I run 2 similar VMs, which allocate memory the same way, chances are good some of it can be shared. And will not remain to be allocated twice.

You should not do this for critical applications. I think it’s good that Vmware disabled this since ESXi 6.0, because it’s a sensitive approach to have more secure defaults. The security concern is that an attacker could mess with the page integrity, and perform inter-VM memory attacks.

This here is my hacky setup. There are many like it, but this one is mine. Alone. The risk is not even moderate here. I am the only risk… But you need to know that this is deactivated by default, in order to benefit from the function.

Results: I can run a lot of VMs on this ESXi, and the memory will probably get deduplicated, similar to Kernel-Same-Page merging with Linux KVM. All the memory are belong to us! Aeh me :slight_smile: Or do you want some?

Linked clones with ESXi and Vmware Workstation - storage efficiency

I have linked clones on Vmware Workstation. Can I just import these to the ESXi? YES. And no.

Option 1: upload the VM, and use vmkfstools to convert the VMware Workstation sparse disk file images to ESXi thin(k) provisioned disk images.

Option 2: export the VM with VMware workstation and upload it.

Option 3: my workflow: qemu-utils can convert between KVM, Vmware Workstation and ESXi

You can do this from a guest:

Vmware Workstation to ESXi: Install qemu-img (the package is qemu-utils on Ubuntu Server 16).

qemu-img convert -f vmdk -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,compat6 WorkstationVM-disk1.vmdk ESXiVM-thindisk.vmdk
scp  ESXiVM-thindisk.vmdk [email protected]:/vmfs/volumes/datastore1/

KVM qcow2 to ESXi:: same package, nearly the same command.

qemu-img convert -f qcow2 -O vmdk -o adapter_type=lsilogic,subformat=streamOptimized,compat6 KVM_VM-disk1.qcow2 ESXiVM-thindisk.vmdk
printf '\x03' | dd conv=notrunc of=<vmdk file name> bs=1 seek=$((0x4)) # if the disk is bootable

vmkfstools might expand the disk image size to the disk size. qemu-img does not, if you prepare the disk image this way. Note that the guest might have faster disk IO with a fully allocated disk image.

Usually you I import a disk image, using -d thin on the ESXi shell:

vmkfstools -i test.vmdk -d thin test2.vmdk
Destination disk format: VMFS thin-provisioned

It’s a 3 step process: convert, copy and import.

Result: using storage (and memory) efficiently with ESXi’s neat features is straight forward. But not directly possible. Wen can migrate to the ESXi from KVM and Vmware Workstation with qemu-img. And back.

Security 1on1: ESXi and you

The basic lessons of information security apply: don’t be naked on the internet. The internet sees you once, and does not forget. Try Youtube. There is proof.

Limit network-access to the management web UI - Road Warrior compromises

As I said: having access to the GUI guests via the Web UI, anywhere, is a killer feature for a Road Warrior like me. Any OS becomes a browser tab, or a little window. On any system. Anywhere.

With the open-vm-desktop tools you can get seamless resizing for Windows and Xserver GUI guests. That’s super neat.

Let’s make this private lab-setup reasonably secure. As a security-aware Road Warrior I want a good compromise between accessibility, availability (what if it dies?) and confidentiality. “I am not as crazy as the crazy people. The crazy people!

  • the hoster (Hetzner) at the data-center offers a “stateless firewall”, which is configurable via a Web site. Just like AWS Security Groups. I can restrict network access to some ESXi services. But the ESXi Web UI isn’t just used for management. It’s also used to interact with the guests. That’s bad design actually.

It’s on a public IP. But that doesn’t mean everyone needs to be able to connect to it. In fact if you don’t restrict it, chances are good that you will be locked out of your ESXi >= 6.0 quickly.

At least block access to 443 and 22 (if you use SSH). Pro tip. YOU will be locked out as well. Because the ESXi account with the login failures gets locked out. That can also lead to internal DoS scenarios… Strange design. Fail2Ban would block the attacker’s IP only. Why block access completely?

There are tons of services on a ESXi, which could be naked on the internet. I blocked TCP 22, 80 and 443 and it looks like this afterwards:

nmap -PN -sV -O2 $IP                                                                                                                                                                                    
427/tcp  open   svrloc?
902/tcp  open   ssl/vmware-auth VMware Authentication Daemon 1.10 (Uses VNC, SOAP)
5988/tcp closed wbem-http
5989/tcp closed wbem-https
8000/tcp open   http-alt?
8300/tcp open   tmi?

Ok, time to learn about the ESXi firewall.

ESXi has got a firewall... fire wall I say

The ESXi has its own firewall, which you can use as well. Let me show you how this works.

[[email protected]:~] esxcli network firewall ruleset rule list
Ruleset                   Direction  Protocol  Port Type  Port Begin  Port End
------------------------  ---------  --------  ---------  ----------  --------
sshServer                 Inbound    TCP       Dst                22        22
sshClient                 Outbound   TCP       Dst                22        22
nfsClient                 Outbound   TCP       Dst                 0     65535

Thing is: I have already taken care of 22, 80, and 443. Now I will take care of the rest. I take care of these ports separately to be able to disable the rules independently. To maintain access.

Relevant entries are:

CIMSLP                    Inbound    TCP       Dst               427       427
NFC                       Inbound    TCP       Dst               902       902
CIMHttpServer             Inbound    TCP       Dst              5988      5988
CIMHttpsServer            Inbound    TCP       Dst              5989      5989
vMotion                   Inbound    TCP       Dst              8000      8000
faultTolerance            Inbound    TCP       Dst              8300      8300
  • CIM(slp) and the HTTP servers belong to a vCenter health monitoring service function
  • NFC is a file-copy service for vSphere. BUT the port 902 is for vmware-authd, which is a multiplexer service. If you firewall this, you might lose access to the VMRC host application, due to authentication issues.
  • a single-host Road Warrior ESXi does not need vMotion. I can firewall this out.
  • Same for Fault Tolerance. Would be nice, but not today.


esxcli network firewall ruleset set --allowed-all false -r NFC
esxcli network firewall ruleset allowedip add --ruleset-id NFC --ip-address

Verify with Nmap or Netcat:

nmap -PN -sV -p 427                                                                                                                                                                                   ...
427/tcp filtered svrloc

I know it’s ugly. But does the trick here. Done.

  • I decided on a way to securely expose the web UI via another path. In fact this isn’t a lot of work, and a straight forward matter if you do it right.

Sophos UTM Community Edition - Road Warrior ESXi is no longer naked on the internet. Security Gateway.

Underpants. Always.

Sophos UTM is an advanced solution for lab-hacking / home labs / private users. It could replace pfSense, but I prefer pfSense because I know FreeBSD quite well. PF is very powerful, and a great OpenSource packet filter.

And UTM isn’t perfect. Far from it. And no, I also don’t want some “junk-loaded proprietary consumer software firewall”, unless it has got significant advantages. I use UTM in conjunction with pfSense. It’s not mutually exclusive. Actually UTM is an RPM based Linux. It origins from Astaro, which was bought by Sophos a while ago. For many Startups and small businesses these gateways did a great job.

  • it becomes an internal security gateway
  • The UTM Reverse Proxy and Reverse Authentication module is powerful, but not powerful enough. The ESXi 6.5 uses web sockets for the Web Console. UTM does not support this.
    • Nginx nowadays does support reverse-proxification of web socket using web apps (I will show you an example).

      • the ESXi web stack has problems with Basic Auth headers. I use Basic Auth to to segregate the Web UI functions from “the internet”. And that includes you. Kind of…
    • UTM however has a nifty function to handle this. Nginx can void the headers, and that works fine.

    • The access concept is:

      • a) I use the powerful VPN functions of the UTM (HTML 5 VPN, SSL VPN for direct access to the ESXi Web UI (has some mobile browser support), …)
      • b) I can use the ESXi VMRC application as well, via iptables port forwarding
      • c) SSH remote access via a jump host, via pfSense NATing
UTM 1 on 1 - doing the do with Reverse Proxy Kung Foo. Web App Firewall.

Setup a Reverse Proxy for the VMware web UI via the good old UTM9 admin panel. The Real Webserver is the VMware web UI.

For Virtual Webservers it’s best practice to create a unique firewall profile. The interface is just a leg, an internal IP which gets provisioned via pfSense DHCP.

We can NAT the IP out with pfSense. Just give the UTM VM some LAN ports in the vSwitch, let UTM grab a DHCP address, and make it static afterwards. If you want the UTM to be an internal secondary gateway, that can also be done. Later. This here is 1 on 1. You’d probably use another vSwitch and VLAN for that. Because you can.

For the Site Path add some Reverse Authentication (I use forms):

For the Reverse Authentication method definition make sure to tick the Remove Basic Header box.

Here is how that will look, in front of the ESXi 6.5 web. You will have to log in twice, of course. The first login is to segregate the internet from messing with the sensitive Vmware Web Ui. Just a noise blocker.

You can get access via:

  • an SSH Jump host, which is NAT’ed out via pfSense
  • The UTM Reverse Proxy (limited)
  • An Nginx web socket reverse proxy hack (see below)
  • by removing the firewall rules at the hoster via robot (emergency)
  • via the UTM VPNs

Just not naked. Is that too much to ask?

UTM's VPN features are worth the effort. Remote Access.

This is an HTML 5 VPN. It’s like Twitch or Youtube forwarding of internal apps. :slight_smile: Or just HTML VNC alike. Ok.

UTM also has got an SSL VPN, and loads of VPN features I do not even touch. IPsec as well.

I have used the OpenVPN Access Server, and in the free version I can get 2 concurrent connections. With UTM I can get as many concurrent connections as I want, which means that I will use it much more. It also allows up to 50 users for the free home edition. And the SSL VPN is OpenVPN based.

Preferably I’d like to avoid that my ISP ever sees any cleartext traffic, and route it all via the VPNs.

Results: UTM is okay. But without web socket support it’s a quirky fit for this setup. UTM’s VPN features are good, and some other apps I host do not need web sockets. - But it’s 2017. Come on, Sophos.

I think UTM is good enough to consolidate security features here. You can also use UTM as your Endpoint Protection, IDS / IPS etc… Keep in mind that it blocks by default, and that configuring an UTM needs some skills, especially log reading and basic familiarity with OpenSource security tools.

Alternative: use Nginx as a Reverse Proxy

The internal IP here is

server {
        listen 443 ssl;
        server_name kazumi.static;

        ssl_certificate /etc/nginx/ssl/nginx.crt;
        ssl_certificate_key /etc/nginx/ssl/nginx.key;

        location / {
                # root /var/www;
                # exclude internal nets from basic auth
                satisfy any;
                deny all;

                proxy_http_version 1.1;
                proxy_ssl_verify off;

                proxy_pass_header Server;
                proxy_redirect http:// $scheme://;
                proxy_redirect off;
                proxy_set_header Host $http_host;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto https;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Scheme $scheme;
                proxy_connect_timeout 10;
                proxy_read_timeout 120;

                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";

                auth_basic "Restricted stuffzzzz";
                auth_basic_user_file /etc/nginx/.htpasswd;
                # strip headers to avoid confusing the internal ESXi web stack
                proxy_set_header Sec-WebSocket-Extensions "";
                proxy_set_header Authorization "";




Maybe I will find another way to get Basic Auth working here. Not for now. This works fine now.

Of course completely unsupported by VMware.

If you want to use this internal host, and also click the VMRC links directly, you need to port-forward port 902 (UDP and TCP afaik) of the vmware-authd.

nc -v 902 # can we connect to the vmware-authd service from the reverse proxy host

sudo sysctl net.ipv4.ip_forward=1
sudo iptables -t nat -A PREROUTING -p tcp -d --dport 902 -j DNAT --to-destination
sudo iptables -t nat -A PREROUTING -p udp -d --dport 902 -j DNAT --to-destination
sudo iptables -t nat -A POSTROUTING -j MASQUERADE

And test it from another system:

nc -v 902
Connection to 902 port [tcp/*] succeeded!
220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC , VMXARGS supported, NFCSSL supported/t

You can also use HAProxy. Or an Nginx module.

The vmrc -? help page (for the standalone console version 10) says that wss:// is the display communication protocol. Interesting, isn’t it.
There are multiple display protocols here. For VMware Horizon it’s Teradici PCoIP (UDP and bitmap based). They use Blast if you need remote GPUs and low-latency remote displays.

This kind of a forwarding and proxy setup has interesting options for protocol analysis. You could also use Burp, of course. If you were into a security analysis of the Vmware web VNC. :wink:

But related to the setup, the options include to use the UTM to NAT or smart-route this. But I wanted to remain independent of it here.

Side note: The UI of this screenshot is German, because my browser spricht gerne Deutsch . Don’t worry. More importantly: you should use a valid SSL cert.

ESXi updates - no VSphere attached

Check the ESXi update tracker. Upload an upgrade package into the datastore. And check it out:

[[email protected]:/bin] esxcli software sources profile list -d /vmfs/volumes/datastore1/utils/ 
Name                             Vendor        Acceptance Level
-------------------------------  ------------  ----------------
ESXi-6.5.0-20170404001-standard  VMware, Inc.  PartnerSupported
ESXi-6.5.0-20170404001-no-tools  VMware, Inc.  PartnerSupported

And install a profile.

[[email protected]:/bin] esxcli software profile update -d /vmfs/volumes/datastore1/utils/ -p ESXi-6.5.0-20170404001-standard
Update Result
   Message: The update completed successfully, but the system needs to be rebooted for the changes to be effective.
   Reboot Required: true
   VIBs Installed: VMW_bootbank_ehci-ehci-hcd_1.0-4vmw.650.0.14.5146846, VMW_bootbank_ixgben_1.0.0.0-9vmw.650.0.14.5146846, VMW_bootbank_misc-drivers_6.5.0-0.14.5146846, VMW_bootbank_ne1000_0.8.0-11vmw.650.0.14.5146846, VMW_bootbank_vmkusb_0.1-1vmw.650.0.14.5146846, VMW_bootbank_vmw-ahci_1.0.0-34vmw.650.0.14.5146846, VMware_bootbank_esx-base_6.5.0-0.19.5310538, VMware_bootbank_esx-ui_1.18.0-5270848, VMware_bootbank_vsan_6.5.0-0.19.5310540, VMware_bootbank_vsanhealth_6.5.0-0.19.5310541

Aaaaand reboot. For a single-node cluster you do not need to take care of Maintenance mode. Obviously :slight_smile:

I think this is the newest build, which also takes care of the compatibility issues with Goog Chrome.

Result: updating the ESXi is a 3 step process. Upload. check and install. With vSphere this is easier.

ESXi 6.5 quirks and issues

Starting and editing a shutdown guest yields the error "not allowed in current state"

Known issue: Sometimes guests “de-sync” with the ESXi host. This is known to savvy Vmware Admins. Un-register the guest, and Re-register the VMX with the ESXi node. If that does not help, you might need to coordinate a restart. With a vSphere setup the procedure is similar.

wget on ESXi doesn't handle https for ISO downloads

Surprise: it’s often not possible to download ISOs directly on the ESXi Shell with wget, because it’s built without SSL support. Sometimes there is a http download, but often there isn’t.

Uploading ISOs can be time-consuming. The solution is to use a local guest for the download, and to scp the file to the ESXi. A GUI guest can be helpful here, if registration and other means of authentication are necessary. Like at MSDN subscriber portals.

Typing issues on guest consoles via Web UI

Bug: I had the issue that characters which I typed on the console, appeared multiple times. Sometimes there was a long delay, and some characters repeated very often, and flooded the prompt or the Web UI form fields.

I upgraded the ESXi, and the Embedded Host Client especially. With version 6.5.0 (Build 5310538) this issue is not present any more on Chrome 58 and Firefox 53. For me is appeared with FreeBSD. A possible solution is outlined here.

Install a new VM from an uploaded OVA file

Surprise: you cannot import a OVA file from the local ESXi datastore directly. DUH!

[[email protected]:/vmfs/volumes/.../ISO/wazuh] tar -tf wazuh2.0.ova 

tar -xvf the OVA and setup a new VM with an existing disk. The disk image format is compatible with ESXi here. If not, you might need to use a conversion tool at a guest, and scp the converted file into the ESXi datastore.

If you un-tar a big OVA container on an ESXi you might find out, that this can take a lot of time. It’s possible to do this on a guest as well, which could be faster.


I could write an ESXi hardening guide. But CIS already has good benchmarks. So this is just an exploration. Not in any way a serious attempt to utilize the free ESXi in production.

Apart from that the exploration of it was a success. I briefly touched topics, such as:

  • performance optimization (ESXi same-page merging - memory optimization)
  • Vmware vSwitch’ing, and guest NATing with pfSense
  • Reverse Proxies, Reverse Authentication etc. with UTM and Nginx
  • Setting up firewall rules with esxcli
    • Doing port scans and connection checks to verify network settings
  • setting up external and internal gateways with a vSwitch topology
  • setting up a VPN… may the road war begin.
    • I pitched the concept of SSL and HTML5 VPNs - useful stuff
  • and I covertly inspired you to setup security gateways to control network setups
  • I hope I got you interested in websocket implementations. Many client / server apps start to use this. ESXi >= 6, Slack, some of the Atlassian products… Websockets aren’t easy to handle.

Building a Road Warrior system was fun, and it works for me.

It’s all amateur level, but super cheap as well. I wouldn’t host online banking like this. Obviously.
But that’s besides the point, to be honest. The point is to open the door for exploration.

This isn’t the easiest setup. Some folks will prefer KVM qemu and libvirt. It makes more sense for a single node setup. The Vmware ESXi design isn’t made for this kind of single-node dedicated server setup.But I just use this for now.

There are no limits[tm].

Version history
  • 12.06.2017 - brain dump - publish
  • 13.06.2017 - added ToC, a little more structure
  • 14.06.2017 - corrected error: vmware-authd on port 902 does not seem to use a websocket protocol, added the nginx IP whitelisting and Basic header removal config lines. Added qcow2 -> vmdk (bootable) migration path from KB article
  • 15.06.2017 - clarified the image import steps. The import happens on the ESXi shell.
  • 16.06.2017 - added link why websockets are “interesting” from a security perspective