VxRail Installation Step by Step Video

I have created a step by step video of VXRAIL initial configuration, which will help you with the initial configuration of the VXRAIL Appliance, however, before you proceed with the initial configuration of your new VxRail appliance, make sure the TOR (top of rack switch is properly configured to support VXRAIL installation requirements).

It is critical to an efficient, successful installation to completely capture and confirm all network elements, IP, ToR Switch details, VLAN information as described in the Pre-Installation Checklist.

Also make sure to have a NTP, DNS and Active Directory (optional) in place before starting the installation.  I have configured the NTP, DNS and Active directory on single VMware workstation machine for the demo purpose.  You will not be able to configure the appliance in case appliance not able to reach the NTP server.

Plan the network configuration in advance and configure the switch prior to configuring the appliance. You have two option here, either use a flat network (not recommended) in which your management traffic, vMotion traffic and VSAN traffic use the same native VLAN or define the VLAN on your switch for Management, vMotion and, VSAN and any other traffic type you want to isolate with VLANs.

I have used the following VLANs on my VXRAIL appliance:

  • Management VLAN 10
  • vMotion VLAN 20
  • VSAN VLAN 30

It’s also imperative to configure all the ports connected from the VXRAIL appliance to the TOR switch as trunks and define all the VLANS to each trunk interface. The tagging and untagging will happen on the virtual switch level.1.png

You need to reserve static IP address for the below components.

  • 4 continuous IP address for ESXi hosts (for 1 appliance)
  • 4 continuous IP address for vMotion Network (for 1 appliance)
  • 4 continuous IP address for VSAN network (for 1 appliance)
  • 1 IP address for vCenter Server Appliance
  • 1 IP address for vRealize Log insight
  • 1 IP address for VXRAIL Manager
  • 1 IP address for VXRAIL Manager Extension
  • IP address of NTP , AD and DNS Servers


Now, you can start the VXRAIL installation referring to the steps below:

  1. Configure the PC, you are using to perform the configuration from, to connect to an address on the same subnet as the VxRail appliance (default is 192.168.10.x).
  2. Connect your PC to a port on the TOR switch integrated with the VxRail appliance.
  3. Confirm that you can ping the VxRail initial IP address (default is Make sure you use either Google chrome or Mozilla Firefox. IE will not able to reach the default IP address
  4. Confirm that the gateway is reachable.
  5. Confirm that the DNS server(s) are reachable (unless you are in an isolated environment).
  6. Connect to VxRail Manager, as follows, referring to the Pre-Installation Site Checklist:
  7. Launch a browser on your PC.
  8. Browse to the VxRail Manager IP address:

The VxRail Welcome screen is displayed. From there onwards please refer to the below video to complete the installation of VXRAIL.

VXRAIL Installation

I will be publishing some more videos  regarding initial configuration in coming weeks .

VMs Sizing Example for EVO: Rail / EMC VSPEX Blue Performance appliance

I have been thinking about writing a blog post on how many VM’s can be hosted on an EMC VSPEX Blue HCIA. There is no straight answer to this, it depends on the VM resource requirements. I have considered a General Purpose VM Profile of 2 vCPU, 4GB of memory and a single 40GB VMDK.

Before going into the sizing details, let us review the total Hardware resources available in EMC VSPEX Blue Performance appliance powered by VMware EVO:Rail.

8-8-2015 4-04-40 PM

Total resources per appliance are:

Processor: 48 Cores {4 x 12 cores}

Memory: 768 GB {4 x 192 GB}

Storage: 1.6 TB of SSB {will be used a read cache and write buffer only}

14.4 TB Raw Storage on 10K SAS drives {4 x 3.6 TB}

Network: 8 x 10GbE NIC

4 x 1GbE NIC {for remote management}

In the following example, I am considering to deploy 100 virtual machines in Hybrid Virtual SAN cluster. Each virtual machine requires 2 vCPU, 4GB of memory And a single 40GB VMDK. This deployment is on a hybrid configuration, which is Running Virtual SAN 6.0 and on-disk format v2. I am going with a conservative approach with vCPU-to-core consolidation ratio of 5:1. The estimation is that the Guest OS and application will consume 50% of the storage.

However, the requirement is to have enough storage to allow VMs to consume 100% of the storage eventually. The only VM Storage Policy setting is NumberOfFailuresToTolerate set to 1. All other Policy settings are left at the defaults. The host will boot from an SATADOM which is there in every node.

Note that we are not including the capacity consumption from component metadata Or witnesses. Both of these are negligible.Taking into account the considerations above, the calculation for a valid configuration would be as follows:

Host Requirements: 4 hosts for Virtual SAN

Total CPU Requirements: 100 x 2 vCPUs = 200 vCPUs

vCPU-to-core ratio: 5:1

Total CPU Core Requirements: 200 / 5 = 40 cores required

How many cores per socket= 6

Total Memory Requirements:

100 x 4GB

= 400GB

 Total Storage Requirements (without FTT): *

100 x 40GB

= 4TB

 Total Storage Requirements (with FTT): *

4TB *2

= 8TB

 Total Storage Requirements (with FTT) + VM Swap (with FTT): *

8 TB + {2 x (100*4)}

= 8 TB + 800 GB

8.8 TB

Since all VMs are thinly provisioned on the VSAN datastore, the estimated storage

Consumption should take into account the thin provisioning aspect before the flash requirement can be calculated.

Estimated Storage Consumption (without FTT) for cache calculation:

(50% of total storage before FTT))

50% of 4TB

= 2TB

  • Cache Required (10% of Estimated Storage Consumption): 200GB
  • Estimated Snapshot Storage Consumption: 0 (keeping this example simple)
  • Total Storage Requirements (VMs + Snapshots):
  • = 8.8TB

 required capacity slack space: 30% {VMware recommendation for VSAN}

 Total Storage Requirement + Slack space:

8.8TB + 2.64TB

= 11.44TB

estimated on-disk format overhead (1%): 114GB**

* Thin provisioning/VM storage consumption is not considered here.

** On-disk format overhead calculation is based on the total storage requirements of capacity layer, so may differ slightly based on final capacity layer size.

CPU Configuration

In this example, the customer requires 40 cores overall. If we take the 10% Virtual

SAN overhead, this brings the total number of cores to 44. The VSPEX Blue appliance has 4 nodes where each node contain and a dual socket system provides 12 cores. That gives a total of 48 cores across the 4-node cluster. This is enough for our 44 core requirement across 4 servers. It also meets The requirements of our virtual machines should one host fail, and all VMs need to Run on just three hosts with a minimum impact to their CPU performance.

Memory Configuration

Each of the 4 Node would need to contain at least 100GB of memory to meet the running requirements. Again, if a host fails, we want to be able to run all 100 VMs on remaining three Node, so we should really consider 140GB of memory per Node.This also provides a 10% overhead for ESXi and Virtual SAN from a memory Perspective. Each VSPEX Blue Performance node contains 192 GB , so we are good to go from memory requirement point of view.

Storage Configuration

For this configuration, a total of 8.8TB of magnetic disk is required, and 200GB of Flash, spread across 4 Nodes. To allow for a 30% of slack space, the actual capacity of the cluster must be 11.44TB. Added to this is the formatting overhead of the v2 Virtual SAN data store. This is Approximately 1% that equates to 114GB. The capacity required is now 11.55TB.

Since we have already factored in a “failures to tolerate”, each host would need to be configured to contain approximately 2.9TB of magnetic disk and approximately 50GB of flash. We advocate following the Virtual SAN best practices of having

Uniformly configured hosts. Each Node in VSPEX Blue applaimmce has 400 GB Flash and 3.6 TB Capacity on 10K SAS drives , which will easily support the storage requirements of 100 VMs with the given profile.

Component Count

The next step is to check whether or not the component count of this configuration would exceed the 3,000 components per host maximum in Virtual SAN 5.5, or the 9,000 components per host maximum in Virtual SAN 6.0 (disk format v2). This 4-Node Virtual SAN cluster supports running 100 virtual machines, each virtual Machine containing a single VMDK. There is no snapshot requirement in this Deployment.

This means that each virtual machine will have the following objects:

  • 1 x VM Home Namespace
  • 1 x VMDK
  •  1 x VM Swap
  • 0 x Snapshot deltas

This implies that there 3 objects per VM. Now we need to work out how many components per object, considering that we are using a VM Storage Policy setting that contains Number of Host Failures to Tolerate = 1 (FTT). It should be noted that Only the VM Home Namespace and the VMDK inherit the FTT setting; the VM Swap object ignores this setting but still uses FTT=1. Therefore when we look at the number of components per object on each VM, we get the following:

  •  2 x VM Home Namespace + 1 witness
  •  2 x VMDK + 1 witness
  •  2 x VM Swap + 1 witness
  • 0 x Snapshot deltas

Now we have a total of 9 components per VM. If we plan to deploy 100 VM, then we Will have a maximum of 900 components. This is well within our limits of 3, 000 Components per host in Virtual SAN 5.5 and 9,000 per host in 6.0.

Conclusion:  EMC VSPEX Blue Performance appliance can run 100 General purpose server workload with FTT = 1 {Failure to tolerate} without any performance impact. It also shows that you can start small with one appliance and grow as you want linearly as shown below.

8-8-2015 4-27-38 PM

I hope this blog was helpful.