Unable to start PernixData FVP Management Server – service-specific error code 0
Having finally got some SSDs to be able to use my PernixPro/PernixPrime NFR license, I thought it was about time to get PernixData’s FVP 2.0 running in my lab again. I haven’t used FVP in my lab since it was running in beta, so I was keen to see the awesome new features in action. It really is an easy install process and took me less than an hour to get my cluster up and running with VMs I/O being accelerated.
That was Friday evening – over the weekend my lab patched, and when I rebooted my FVP Management Server, the service refused to start:
Windows could not start the PernixData FVP Management Server on Local Computer
On checking the Event Log, it was as useful as a chocolate teapot:
Next, I checked the PernixData FVP log files (located in C:\Program Files\PernixData\FVP Management Server\Server\log, or your install location). Within the commons-daemon log file, a little more useful information:
[2014-10-27 09:31:17] [error] Failed creating java
[2014-10-27 09:31:17] [error] ServiceStart returned 1
At this point I double-checked the version of the Java run-time I had installed and noticed that it was the 32-bit version, rather than the required 64-bit.
PernixData FVP actually installs the correct Java runtime when you install it. My mistake was that when I went to activate my PernixData license, I installed the 32-bit JRE in order to run the activation process in the browser – at which point my FVP service would no longer start. I completely removed the 32-bit version and installed the 64-bit JRE and the service started perfectly!
Installing VMware vSphere Update Manager Download Service and publishing via IIS
The vSphere UMDS provides a way to download patches for VMware servers that have an air-gap, or for some reason aren’t allowed to go out to the internet themselves – in my case a security policy prevented a DMZ vCenter Server from connecting to the internet directly. The solution is to use UMDS to download the updates to a 2nd server that was hosted in the DMZ and then update the vCenter Server from there. It also can save on bandwidth if you’re running multiple vCenter Servers, which again was the case (though bandwidth isn’t really a constraint). (more…)