vSphere & IPv6: how VMRC breaks it all

It’s been a bit quiet around my vSphere pure IPv6 lab setup lately. At first it seemed to be surprisingly easy, but the devil’s in the details…

As already posted, the initial setup went without any problems. The setup required IPv4 just for the kickstart process, or to be more exact for the first boot and installation phase. During the final configuration script the DHCP IPv4 address was dropped and the ESXi hosts were running IPv6 only:

IPv6 vmkernel networkingIn this setup the vCenter Server Appliance was deployed on my workstation PC and connected directly to the management (V)LAN using a dedicated NIC port on the PC. The vCSA was configured with just an IPv6 address, no IPv4. The DNS server was set up with AAAA records for all hostnames only, which means there was no IPv4 address for the respective hostnames available.

The first tests were running perfectly. Internal communcation was functioning, even the NFS and iSCSI storage connections to the Debian 7 based NAS were working without any problem:

IPv6 iSCSIConnected to the vCSA with the fat client, logged in to the Web Client – all good. Fired up a VM, vmotioned it around – no problem. Then I created a new VM for a Windows Server 2012 test installation, started the VM, connected to the console…

Nothing. Could not connect.

By habit I had used the fat (C#) client. Yeah I know, deprecated. But I still don’t like the Web Client for several reasons – sluggish, not clearly arranged (or at least not intuitive), screen space wasted for graphics instead of information… hell, I really don’t like it. Plus it is the only reason why I still need to have the buggy & vulnerable Flash Player installed. </rant>
So the IPv6 support would be a very valid reason to switch to the Web Client, but again that was to no avail. The remote console could not connect to the ESXi.

Next thing to do was to add an IPv4 address to the management network, which means to both the ESXi and vCSA. I configured the addresses and added an additional DNS A record for the hostnames. Bingo – the fat client opened console sessions to the VMs without any problems, although I connected to the vCSA with IPv6. Tried the same with the Web Client and ran into a strange error message:

SSL verification failure for “vcenter.dus.vaspects.com” due to a host thumbprint mismatch: stored thumbprint “<long hex number>” does not match certificate thumbprint “<different long hex number>”.

Take notice that I already had a working connection to the vCSA, this error message appeared in the newly opened remote console tab of the browser (which was Firefox BTW, but I tried others and that didn’t make any difference). A very rare error message it seems and from a community posting I assume it is related to multiple DNS entries for the ESXi or vCenter hostnames, thus not caused by or limited to the dual stack setup.

After several unsuccessful attempts to find a workaround I gave up and switched the management network back to IPv4 only, with single A records for all hostnames.

Bottom line: no remote console in vSphere without IPv4, so the inability of the VMware Remote Console [plugin] to handle IPv6 breaks the whole thing. And the new Web Client is even worse than the discontinued fat client.

Leave a Reply

Your email address will not be published. Required fields are marked *

*

code