VMware Fling: ESXi Embedded Host Client

I almost choked on my coffee this morning when I saw William Lam announcing a new VMware Fling called ESXi Embedded Host Client. Finally the day when we can get a local vSphere Web Client on a standalone host is here, and it’s not a moment too soon. This feature has been missing since ESX 3 and it’s VMware Infrastructure Web Access. For now, this is a Fling (which means unsupported and so on), but I really hope that this ends up being built-in to ESXi very soon — even on the free vSphere Hypervisor.

So, what does it look like? Well, to be honest it looks pretty darn awesome, and you know what? No Flash! Yes, it’s HTML5 baby!

VMware ESXi Host Client

If you are running ESXi 6, installation is as easy as installing a .vib (in ESXi 5.5 there is a workaround to get it running, highlighted in Williams post). So, give it a spin and make sure to provide feedback on the Flings site to help ensure VMware sees that we as users of their products want this feature to be core to vSphere in upcoming releases. Make your voice heard, and make sure the team who is behind this get the credit they deserve.

Fixing “Could not create vFlash cache” error when powering on a VM

During some way overdue housekeeping in my HP Microserver-based “Homelab” today, I ran into a rather annoying issue that prevented me from starting one of my more important VMs; namely my home Domain Controller.

In short, I removed an old SSD drive that I’ve used for vFlash Read Cache (vFRC) testing and installed a new 1TB drive instead. Since I have a rather beefy work lab now, I need space more than speed at home, so this seemed like a good idea at the time.

A good idea that is, until I tried starting my DC VM, which also is my DNS and DHCP server, and got greeted with this little gem:

Zappa-SSD-Failure

The “Could not create vFlash cache: msg.vflashcache.error.VFC_FAILURE” error is understandable, the SSD drive was removed, but I honestly did not think that even if a VM was configured to use it, that it’s absence would prevent a power-on operation on that VM. I would have expected it to throw a warning about the cache location missing, and warn me that acceleration was not happening, not a flat out “cannot power on“.

Normally the fix for this would be quick and easy, edit the VM and remove the vFRC configuration, but since my host has a whopping total of 8GB of memory I don’t have vCenter running at all times.  Editing the VM settings through the vCenter Legacy Client (C#) does not work, since vFRC requires Virtual Hardware Version 10, which it cannot edit.

Once I got the vCenter Server Appliance (vCSA) fired up, I realised that I have somehow forgotten the admin AND root passwords, and was completely unable to log-on. How that has happened is beyond me, but for the life of me I was not able to log on.

Next step was to try and edit the VM from VMware Workstation 10 installed on one of the Windows boxes in my network. Sadly Workstation has no concept of vFRC, and it is not possible to edit that particular VM setting, even if you connect it to the vSphere host. I later on also realized that VMware Workstation 10 is also unable to host connect  USB peripherals, like printers, to a VM, but that’s beside the point right now.

So, either trying to hack the VM Hardware Version to a value that the vSphere Client can handle, of  deploying a new vCSA instance, I was left with editing the VMs vmx file directly.

Thankfully this was an easy way to fix the problem, and get the VM powered on. For each vmdk file that is configured to use vFRC, there is a corresponding entry in the vmx file, that controls vFRC.

In order to turn off vFRC acceleration for a given disk, download the vmx file, and change the value for <device>.vFlash.enabled from
[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
sched.scsi0:2.vFlash.enabled = “TRUE”
[/cc]
to
[cc lang=”bash” width=”100%” theme=”blackboard” nowrap=”0″]
sched.scsi0:2.vFlash.enabled = “FALSE”
[/cc]

Re-upload the vmx file, and try to power on. In my case, this fixed the problem of powering on the VM.

This problem again highlights one of the problems with the dependancy on the new vSphere Web Client. In a real production environment, the vCenter would be up and running at all times, and editing the VM would have been a small task, but what if you had used vFRC to speed up vCSA itself, and you had a failed SSD drive?

Of course, in this case the fault is mostly mine. I removed a “production SSD”, without first removing the vFRC configuration. I did not have a working vCSA with Web Client up and running when this was done, and I had forgotten my passwords. A pretty specific error generating procedure if there ever was one.

It’s an easy fix to edit the vmx file, but it does at times feel a little bit like you are now able to cut of the branch you are sitting on with the new vSphere Web Client. In simpler days, you could pretty much fix anything by connecting the vSphere Client to the host and fix any errors there, but now the dependancy on the vCenter Server is stronger than ever.

Before upgrading your VMs to Hardware Version 10, make sure you understand the implications of going all-in with dependancies on the Web Client and vCenter. It might just come back and bite you if you haven’t thought through your design.

vSphere Web or Desktop Client – Who´s Your Daddy?

At the moment, VMware vSphere offers two different management clients, the vSphere Web Client and the vSphere Desktop Client.

The feature comparison table looks like this:
(Copied from “Which vSphere client should I use and when?“)

vSphere Web Client Only vSphere Desktop Client Only
  • vCenter Single Sign-On
    • Authentication
    • Administration
  • Navigation with Inventory Lists
  • Inventory Tagging
  • Work In Progress (Pause)
  • Pre-emptive Searching
  • Save Searches
  • Enhanced read performance utilizing the Inventory Service
  • vSphere Replication (not SRM)
  • Virtual Infrastructure Navigator
  • Enhanced vMotion (no shared storage)
  • Integration with vCenter Orchestrator (vCO) Workflows (Extended Menus)
  • Virtual Distributed Switch (vDS)
    • Health Check
    • Export/Restore Configuration
    • Diagram filtering
  • Log Browser Plugin
  • vSphere Data Protection (VDP)
  • VMware Desktop Plug-ins (VUM, SRM, etc)
  • 3rd Party Desktop Plugins (various)
  • VXLAN Networking
  • Ability to change Guest OS on an existing virtual machine
  • vCenter Server Maps
  • Create and edit custom attributes
  • Connect direct to a vSphere host
  • Inflate thin disk option found in the Datastore Browser

;

In plain words, this means that all new features in vSphere 5.1 are Web Client only, and older “legacy” features and plugin integrations are Desktop Client only at this point.

This will change over time as both VMware products, like VUM and SRM, are moved into a new home in the Web Client and when 3rd party vendors integrate their plugins with the new client.

There is no doubt that the vSphere Web Client is where the future lives, but in the interim vAdmins are forced to utilize both to be able to use all the available functionality and obviously this is far from ideal.

I´m sure VMware will get where they want with the vSphere Web Client in the end, and changing platform like this is a big task, especially when you consider that third parties need to be on their toes and upgrade their integrations as well.

Having two clients for management is not fun, but it does beat having no management at all.

So in short, your daddy? They both are. While they might be separated, the divorce has not been finalized just yet.