Upgrade to VMware vCenter 6.5U1 failed – Error code 3010

Today we tried to upgrade to the new VMware vCenter 6.5U1. Unfortunately the installer failed with error code 3010.

It turns out that vmware-jre.msi, which is part of the vCenter upgrade installation has failed, because there are some locked files which can not be replaced.

VMware vCenter is running on Windows Server 2012 R2.
This vCenter instance also host a vSphere Plugin for Stormagic SvSAN.

StorMagic SvSAN is a very nice and easy to use software-defined storage solution, which provides a virtual SAN to the VMware vSphere environment using local disks of the ESXi hosts.

StorMagic SvSAN uses an Apache Tomcat Server to present the plugin’s information inside vSphere Webclient. The Tomcat Server Service is the one who holds a lock on the files which vmware-jre.msi tries to replace.


The simple solution is to stop the „StorMagic Apache Tomcat Service“ before running the upgrade of VMware vCenter 6.5U1 and start it after the installation has finished.


How to restore a SvSAN virtual appliance in 3 easy steps

Stormagic SvSAN is a software-defined storage solution designed to deliver hyperconverged compute and storage infrastructure with two or more low-cost servers.

In a disaster scenario when one of the servers has an outage, because of disk failure or any other kind of failures, you are maybe in the situation to restore one of the SvSAN virtual appliances.

Cluster node outage or any other kind of failure.

First of all the best news:
Every SvSAN virtual appliance has by default an automatic backup on any other SvSAN virtual appliance. That means you can easily restore the lost SvSAN virtual appliance from any existing SvSAN virtual appliance.

Here are the steps outlined:
In this scenario in the screenshots we have 3 ESXi host. Please note that this scenario is also fully valid for only 2 ESXi hosts.

All of the screenshots are taken from the Stormagic SvSAN vCenter Web Plugin, which is fully and seamlessly integrated into VMware vCenter WebClient.

In the screenshot below you can see the first and the third SvSAN virtual appliance has synchronization errors because the second appliance is missing – maybe because of a hardware failure of the ESXi or any other failure in the host.

Step 1: Select one of the remaining appliances

You need to select one of the remaining appliances and click Restore…

In the upcoming dialog you are able to select the missing second SvSAN virtual appliance.

Step 2: Select the missing SvSAN virtual appliance

Select the SvSAN virtual appliance which you would like to restore and click Restore…

Step 3: Follow the restore wizard

Now you only need to follow the restore wizard which guides you through the process.

Enter vCenter credentials

Select the ESXi host which has been recovered from its hardware failure and enter the password for root.

Select the datastore onto which you would like to restore the SvSAN virtual appliance.

Adjust your disk pool configuration if necessary.

Select and change networking.

Enter admin credentials.

A few minutes after you have finished the restore wizard, the restored SvSAN appliances shows up. All SvSAN appliances are now in a warning state, because re-synchronization has already been started automatically. Re-synchronization will take a while depending on the size of your synchronized mirrors.

You can also watch the re-synchronization progress using the SvSAN applicance’s web interface.

Hopefully you see in this few screenshots how easy it is to recover your Stormagic SvSAN software-defined storage solution using the builtin wizard driven approach after an outage of a complete cluster node.


Webcast: Erschwingliche Hyper-Konvergenz für schlanke IT-Umgebungen (Hyper-V Cluster ohne externen Storage)

Dieser Webcast zeigt, wie man einen kostengünstigen Microsoft Hyper-V Cluster aus zwei Knoten konfiguriert. Für das Cluster Shared Volume und das Quorum, wird kein externer Storage verwendet, sondern über die lokalen Festplatten der Cluster-Knoten werden mit Hilfe von Stormagic SvSAN mehrere synchrone Spiegel gebildet, die als Quorum und als CSV verwendet werden. So ein synchroner Spiegel wird per MPIO iSCSI-Verbindung an jeden Hyper-V-Knoten angeschlossen. Falls ein kompletter Hyper-V-Knoten ausfällt, bleibt das eine Spiegel-Plex verfügbar und der Hyper-V Cluster, kann dafür sorgen, dass die virtuellen Maschinen geschwenkt werden und verfügbar bleiben.