There was a recent discussion on the forums around the supportability of quad port NICs when deploying the vSphere Storage Appliance. There is an error thrown by the installer when the ESXi host only has a quad port NIC. The error states that the VSA installer ‘Failed to configure network on host’ because it ‘Could not find 2 NICs on the system’. However there is a workaround to allow VSA to install when the ESXi host(s) only contain a single quad port NIC. This is only available on VSA 5.1.x.
Category Archives: vSphere Storage Appliance
Heads Up! VSA Physical Switch Connectivity Check
I’ve been working with my colleague, Rawlinson Rivera, on documenting a few features around VSA deployments. Rawlinson is currently working on a new feature of VSA 5.1 called brownfield install, which basically allows you to deploy the VSA when you already have VMs running on your ESXi hosts.
During the host audit section of the install, we observed the following warning:- NIC ports to physical switch connectivity doesn’t provide both NIC and physical switch redundancy.
This is not something I had observed in previous versions of the VSA (and we were using the same environment). It would seem that this is a new check implemented in VSA 5.1 with vSphere 5.1. The thing to note is that this is just a warning – and its a good warning to have as well, as a single switch failure could impact your whole shared storage environment. Since it is a warning, you can choose to ignore it. It might be that in SMB (Small to Midsize businesses) or ROBO (Remote Office, Branch Office) situations, a second physical network switch is not available or indeed affordable.
The issue is however is that if you have a stackable switch configuration, you will also get this warning. So even though you might have physical switch redundancy in your network, you could still encounter this warning. In that case, it is safe to just ignore the warning and continue with the installation/deployment.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage
Heads Up! VSA Manager 5.1.x – Install Error 2896: Executing action failed
I was asked recently to provide some assistance with a VSA installation problem. The issue which this person experienced is described in the release notes for VSA 5.1.1 .
VSA 5.1.1 installation fails with the Error 2896: Executing action failed message
This problem might occur when the location of the temp drive is set to a drive other than C:, where VSA Manager is to be installed.
Workaround: Make sure that the user and system TEMP and TMP variables point to a specified location on the C: drive.
However this workaround did not work for him and it led to finding another possible cause for this error. If you have your vCenter server installed on a drive other than the C: drive, you may also encounter this installation problem when trying to deploy the VSA Manager. In this case, to resolve this issue, you will need to do the following:
- Run the vSphere Storage Appliance (VSA) Manager installer. The installer extracts and copies the files.
- When the extraction completes, the Next button is enabled. Do not click Next at this stage.
- Navigate to %TEMP%/sva/VSAManager/installTool, and open the runtool.bat file using a text editor.
- In the ninth line of code, add /d before %BUILDDIR%. For example, change: cd %BUILDDIR% to: cd /d %BUILDDIR%
- Save and close the runtool.bat file.
- Click Next to continue with the installation.
This will allow the installation to proceed successfully. I’ll ask to get a KB updated with this information.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage
Heads Up! If running VSA 5.1, you do not need VSA 5.1.1
Folks,
This is currently not very clear in the release notes, but if you are already running vSphere Storage Appliance (VSA) version 5.1, you do not need to update to VSA 5.1.1. This is not needed, nor is it supported.
VSA 5.1.1 focuses solely on fixing issues found during the upgrade from VSA version 1.0. If you have successfully upgraded to 5.1, then you do not need to go to version 5.1.1.
You may run into some ‘strange’ upgrade issues trying to get from VSA 5.1 to VSA 5.1.1. For example, on 2 node clusters which use the VSA Cluster Service, the installer will abort during the upgrade with a “could not stop service” error. This is because the VSA cluster service on VSA 5.1 is called “VSAClusterService-5.1″ but the installer tries to stop a service called “VSAClusterService”, which is the name of the VSA 1.0 Cluster Service.
So, just to repeat, if you are on VSA 5.1, you do not need VSA 5.1.1. We are working on getting this called out very clearly in the release notes.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage
VSA Cluster Service Considerations
Some changes have been made to the VSA Cluster Service in version 5.1. Previously, the VSA Cluster Service was installed on the vCenter Server – there was no way to decouple it. However in VSA 5.1, the VSA Cluster Service is a stand-alone entity. It can still be deployed on the vCenter server, but it can also be deployed outside of it.
As a reminder, the VSA Cluster Service is only necessary in two node configurations. It is not necessary in three node configurations. The VSA Cluster Service provides the tie-breaker code in a two node configuration – it provides the additional vote, which when added to the votes from the VSA nodes, provide 3 votes in the cluster. If one VSA node fails, there is still a quorum of cluster members to keep the cluster running.
The main reason for decoupling the VSA Cluster Service from the vCenter server is to enable ROBO – Remote Office, Branch Office deployments. In these configurations, the vCenter server will typically reside at a central office, and the VSA cluster will reside at a remote office. With three nodes at the remote office, there is no need for the VSA Cluster Service. In two nodes configurations, the VSA Cluster Service is required. And more importantly, the VSA Cluster Service must be deployed at the remote office, on the same subnet as the VSA. If you deploy the VSA Cluster Service on your vCenter server at the central office, and try to use it as the tie-breaker for a remote two node deployment which is on a different subnet, you will get this ‘Cannot Create VSA cluster’ error:
Therefore you will need to deploy a Windows or Linux VM or host at the remote site on the same subnet, install the VSA Cluster Service on that OS, and point the VSA installer to it. This is significantly different to the way things worked in VSA 1.0. In that version, one simply picked a unique IP address for the VSA Cluster Service, and the installer took care of plumbing up that IP address on the vCenter server. In version 5.1, when populating the VSA Cluster Service IP address, you use the IP address of the vCenter server if that is where the VSA Cluster Service is installed. Otherwise if you simply select a unique IP address like you did in VSA 1.0, you will get the error:
Cannot create VSA cluster: Unable to login to VMware Cluster Service at: https://aa.bb.cc.dd:4336/services/pseudosvaservice. Please ensure the service is up, and retry.; nested exception is:
java.net.ConnectException: Connection timed out: connect
The point is that the VSA cluster service must already be installed and running at the IP address you provide before you can proceed with the installation.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage