Skip to main content
Pure Technical Services

Web Guide: FlashBlade VMware vSphere PoC Guide

Currently viewing public documentation. Please login to access the full scope of documentation.

Executive Summary

FlashBlade, the high performance, massively scalable, highly-available Network Attached Storage solution from Pure Storage represents a technologically significant breakthrough in the flash-based storage segment. While the Pure Storage FlashArray offers the best platform for block storage, significant number of customers is interested in deploying Network Attached Storage as their primary means for data storage in physical and virtual environments.

This document focuses on FlashBlade in VMware ESXi deployments and describes how to build a Proof of Concept environment, execute workload tests, and to collect performance data.


The primary audience for this paper are system engineers, solution architects, vSphere and storage administrators, network administrators, and field engineers interested in understanding benefits and technical details of FlashBlade implementation in virtualized, software defined data centers. The essential understanding and knowledge of ESXi, network, and storage is required.


Network File System, the widely-adopted distributed file system that has become an open standard, provides means for shared access to files stored on the NFS server. The NFS datastore support introduced with ESX version 3, greatly extended vSphere’s storage capabilities opening the entire new type of the devices to be deployed in virtualized environments. NFS datastores, conceptually resemble traditional VMFS datastores and may be easily deployed and integrated into existing network infrastructure.

Test Objectives

The primary goal of the testing was to demonstrate FlashBlade’s superior scalability, throughput, and performance when deployed as an NFS-backed datastore in virtualized data center.



FlashBlade is a modern flash-based, file and object storage system designed from the ground up to offer effortless setup, efficient rack space utilization and high storage density. An evergreen upgrade model eliminates the need for forklift upgrades making FlashBlade ideally suited for customers seeking long term array life span. FlashBlade front view is depicted in Figure 1.


Figure 1

The basic building blocks of FlashBlade are the 15-slot chassis and DirectFlash modules (blades). The FlashBlade chassis houses DirectFlash modules and provides management and host connectivity interfaces.

The four Rack Unit single FlashBlade chassis, with 15 populated slots delivers:

  • 1.6 PTB of usable capacity with 52TB DirectFlash modules
  • 17GB/s bandwidth
  • Up to 1 million IO/s
  • 8 40Gbs or 32 10Gb/s network ports for client connectivity
  • Low, 1.8 kW power consumption

Currently supported client protocols are:

  • NFS version 3
  • SMB
  • HTTP
  • S3/Object

FlashBlade Advantage

FlashBlade offers high storage density and expandability that simplifies storage administration, FlashBlade deployment consolidates network address space to a single IP management address and makes possible to have a single mount point IP address while eliminating the need for NFS device-spread.

Moreover, following Pure Storage design principles, FlashBlade also offers an intuitive user interface, allowing simple storage management and provisioning with snapshots as well as online capacity expansion.

FlashBlade Architecture

FlashBlade, with its unique architecture, designed specifically as a scale-out, high-bandwidth, flash-friendly storage array, has created a new class of NAS devices.

The diagram of FlashBlade architecture is shown in Figure 2.


Figure 2

The 15-blade chassis delivers network connectivity via two, redundant Fabric Modules (FMs). Each Fabric Module is equipped with 4 40Gb/s external network ports (uplinks). The Fabric Modules also provide low latency, high throughput Direct Flash (blade) connectivity.

The rear view of FlashBlade with two Fabric Modules is shown in Figure 3.


Figure 3


DirectFlash modules (blades) provide high capacity storage. Off the shelf Solid State Disk (SSD) have a built-in Flash Translation Layer (FTL) which presents the SSD to the storage controller as a traditional spinning disk. The designers of DirectFlash have eliminated FTL exposing “raw” NAND cells to the array’s software. This allows a direct control over I/O scheduling, maximizing the storage parallelism and opening the NAND performance potential for parallel workloads via PCIe/NVMe. Each DirectFlash module consists of the CPU, memory, controllers and NAND cells and is FlashBlade chassis hot-pluggable.

The DirectFlash module is shown in Figure 4.


Figure 4

FlashBlade Technical Specifications

  1. Chassis
    1. 4U
    2. 2+2 redundant power supplies
    3. 1+1 Elastic Fabric Modules
    4. 15 FlashBlade slots
  2. DirectFlash (blade)
    1. Integrated CPU, DRAM, redundant Ethernet links
    2. Chassis management network
    3. Capacity (per blade): 8TB, 17TB, 52TB
  3. Fabric Module
    1. Integrated chassis management module
    2. Four 40Gb/s QSFP+ Ethernet port
    3. Embedded network with load balancing and virtualization

Test Bed Infrastructure

The test bed infrastructure designed for this test included the following hardware and software components – see Figure 5:

  1. Pure Storage FlashBlade
    1. Single chassis
      1. 2+2 redundant power supplies
      2. 1+1 Elastic Fabric Modules
      3. Seven DirectFlash 8TB blades
    2. Two Fabric Modules
  2. Four active 40Gb/s QSFP+ Ethernet ports
  3. Servers:
    1. Four Cisco UCS B200 M4 2 socket with Intel Xeon E5-2600 series processor @2.40 GHz, 128 GB of memory, five 10GB/S vNICs
    2. Supermicro X8DTG-D 2 socket with Intel Xeon E5606 @ 2.13 GHz, 96GB of memory, two 1Gb/s and four 10Gb/s NICs – see Appendix A for VMware Load Balancing (not shown in Figure 3)
  4. Network Switches
    1. Two Cisco Nexus 9396PX
    2. Network Topology – see Figure 5.
  5. Software:
    1. FlashBlade Purity version 2.1.3
    2. ESXi verion 6.5
    3. vCenter Server version 6.5
    4. Windows Server 2016
    5. VDBench version 5.04.06
    6. Pure Storage VDBench GoKit 1.1


Figure 5

Test Bed Configuration

Each ESXi Cisco UCS blade server was connected to eight NFS datastores. The server to datastore (FlashBlade) links were established using two dedicated 10 Gb/s NICs and two dedicated VLANs. The entire network infrastructure supported jumbo frames, however increasing the MTU to 9000 did not result in statistically valid performance improvements. See Appendix B for ESXi and FlashBlade jumbo frame configuration information.

128 Windows 2016 Server virtual machines were hosted by four ESXi servers with 32 VMs per host and 16 VMs on each datastore - see Figure 6.


Figure 6

Each ESXi host was configure with two virtual switches. Every virtual switch had a single 10Gb/s vmnic. IP addresses assigned to each vmnic were on different subnets, for example, host1 was configured with (virtual switch 1) and (virtual switch 2) addresses, host2 was configured with (virtual switch 1) and (virtual switch 2) addresses for NFS datastore connectivity.  This configuration ensured physical as well as logical NFS traffic separation from virtual machine data and management networks. Please note that when creating an NFS datastore on the ESXi host, it is not possible to establish a network connection to an NFS volume by selecting a specific virtual switch. In order to utilize additional network interfaces, separate IP subnets are required for each NFS mount point. The single ESXi host NFS network configuration is shown in Figure 7.

The bandwidth of a single NIC even in multiple vmnic virtual switch configuration is a limiting factor for the NFS datastore I/O operations.


Figure 7

Please note that each Virtual switch and VMkernel port groups are on different IP subnets and the corresponding datastores. This configuration provides optimal connectivity to the NFS datastores by increasing the IO parallelism on the ESXi host as well FlashBlade side.

Load Balancing

ESXi network load-balancing requires a change of the Virtual switch “Teaming and failover” property from “Route based on originating virtual port” to “Route based on IP hash”. Currently the “Route based on IP hash” policy is not supported on Cisco UCS.

 For the steps required to change VMware’s load balancing algorithm see Appendix A.

FlashBlade Configuration

FlashBlade may be configured using web-based HTML 5 user interface (no client installation required), command line or RestAPI.

Configuring Client Connectivity

Create subnet for client (NFS, SMB, HTTP/S3) connectivity

  1. Command Line Interface (CLI):
puresubnet create --prefix<subnet/mask> --vlan <vland_id> <vlan_name>


puresubnet create --prefix --vlan vlan202
  1. Graphical User Interface
    1. Select Settings in the left pane
    2. Select Network
    3. Select ‘+’ sign at top-right in the Subnets header
    4. Provide values in Create Subnet dialog window
      1. Name – subnet name
      2. Prefix – network address for the subnet with the subnet mask length
      3. Gateway – optional IP address of the gateway
      4. MTU – optional Maximum Transmission Unit size, default is 1500, change to 9000 for jumbo frames
    5. Click Create


Figure 8

Create a virtual network interface, assign it to the existing VLAN

  1. Command Line Interface (CLI):
purenetwork create vip --address <IP_address> --servicelist data name


purenetwork create vip --address --servicelist data subnet25_NIC
  1. Using Graphical User Interface – see Figure 9.
    1. Select Settings in the left pane
    2. Select Add interface ‘+’ sign
    3. Provide values in Create Network Interface dialog box
      1. Name – Interface name
      2. Address – IP address where file systems can be mounted
      3. Services – not modifiable
      4. Subnet – not modifiable
    4. Click Create


Figure 9

Creating and Exporting File System

Create and export file system

  1. Using Command Line Interface (CLI):
  purefs create --rules <rules> --size <size> File_System


purefs create --rules '*(rw,no_root_squash)' --size 78GB DS10

For existing file systems modify export rules (if necessary)

purefs setattr --rules <rules> File_System  


purefs setattr --rules '*(rw,no_root_squash)' DS10

where --rules are standard NFS (FlashBlade supported) export rules, in format ‘ip_addres(options)’

* (asterisk) – export the file system to all hosts

rw – file system exported will be readable and writeable

ro – file system exported will be read-only

root_squash – file system exported will be mapped to anonymous user ID when accessed by user root

no_root_squash – file system exported will not be mapped to anonymous ID when accessed by user root

fileid_32bit – file system exported will support clients that require 32-bit inode support

Add the desired protocol to the file system

  purefs add --protocol <protocol> File_System


purefs add –protocol nfs DS10

Optionally enable fast-remove and/or snapshot options

purefs enable --fast-remove-dir --snapshot-dir File_System  
  1. Using Graphical User Interface - see Figure 10.
    1. Select Storage in the left pane
    2. Select File Systems and ‘+’ sign
    3. Provide values in Create File System
      1. Files system Name
      2. Provisioned SizeSelect unit (K, M, G, T, P)
      3. Optionally enable Fast Remove
      4. Optionally enable Snapshot
      5. Enable NFS
      6. Provide Export Rules [*(rw,no_root_squash)]
    4. Click Create

The rw,no_root_squash export rules are recommended for ESXi hosts . It also recommended to export the file system to all hosts (include * in front of the parenthesis) which will allow the NFS datastores to be mounted on all ESXi hosts.


Figure 10

ESXi Host Configuration

To create a Virtual switch and NFS based datastores using vSphere Web Based client follow the steps below:

  1. Create a vSwitch – see Figure 11

a. Select the hosts tab, Host Let me know if this sounds reasonable➤Configure (tab)Virtual switches-Add host networking icon


b. Select connection type: Select VMkernel Network Adapter – see Figure 12.


Figure 12

c. Select target device: New standard switch – see Figure 13.


Figure 13

d. Create a Standard Switch: Assign free physical network adapters to the new switch (click green ‘+’ sign and select an available active adapter (vmnic)) – see Figure 14.


Figure 14

e. Select Next when finished assigning adapters

f. Port properties – see Figure 15.

i. Network label (for example: VMkernelNFS)

ii. VLAN ID: leave at default (0) if you are not planning to tag the outgoing network frames

iii. TCP/IP stack: Default

iv. Available service: all disabled


Figure 15

g. IPv4 settings – see Figure 16.

i. IPv4 settings: Use static IPv4 settings (provide IP address and subnet mask)

ii. Provided the IP address and the corresponding subnet mask

iii. Review settings and finish creating the vSwitch


Figure 16


  1. Verify connectivity from ESXi host to FlashBlade
    1. Login as root to the ESXi host
    2. Issue vmkping command  
vmkping <destination_ip>

Creating Datastore

1. Select the hosts tab, Host➤Datastores➤New Datastore… - see Figure 17


Figure 17

2. New Datastore - see Figure 18.

a. Type: NFS


Figure 18

3. Select NFS version: NFS 3 - see Figure 19



a. Datastore name: friendly name for the datastore (for example: DS10) – see Figure 20

b. Folder: Specify folder where this datastore was created on FlashBlade

c. Server: IP address or FQDN for the VIP on the FlashBlade


Figure 20


When mounting NFS datastore on multiple hosts you must use the same FQDN, name, or IP address and datastore name. If using FQDN, ensure that DNS records have been updated and ESXi hosts have been correctly configured with DNS server IP address.

BEST PRACTICE: Mount datastores using IP addresses

Mounting NFS datastore using IP address instead of the FQDN removes the dependency on the availability of DNS servers.

ESXi NFS Datastore Configuration Settings

As the number of NFS datastores connected with each host increases, it will be necessary to adjust the following ESXi parameters on each ESXi server (see also Table 1):

  • NFS.MaxVolumes – Maximum number of NFS mounted volumes (per host)
  • Net.TcpipHeapSize - Initial TCP/IP heap size in MB
  • Net.TcpipHeapMax – maximum TCP/IP heap size in MB
  • SunRPC.MaxConnPerIp – maximum number of unique TCP connections per IP address


Default Value

Maximum Value

Recommended Value






0 MB

32 MB

32 MB


512 MB

1536 MB

512 MB





Table 1

The SunRPC.MaxConnPerIp should be increased to avoid sharing the host to NFS datastore connections. There is a maximum of 256 NFS datastores with 128 unique TCP connections, therefore forcing connection sharing when the NFS datastore limit is reached.

The settings listed in Table 1 must be adjusted on each ESXi host using vSphere Web Client (Advanced System Settings) or command line and may require a reboot.

Changing ESXi Advanced System Settings

To change ESXi advanced system settings using vSphere Web Client GUI. See Figure 21.

  1. Select Host (tab)->Host->Configure->Advanced System Settings->Edit
  2. In Edit Advanced System Setting windows use the search window to locate the required parameter and modify its value, click OK
  3. Reboot if required


Figure 21

To change Advanced System Settings using esxcli:

esxcli system settings set -o “/SectionName/OptionName” --int-value=<value>


esxcli system settings set -o “/NFS/MaxVolumes” --int-value=16 

Disk Provisioning

For the virtual machines residing on FlashBlade NFS datastores only thin provisioning is supported. Thin provisioning allocates and zeroes disk space to the virtual machine disk on as needed basis.

Post Virtual Machine creation ESXi will report the vmdisk as thick provision eager zeroed - this issue is under investigation. When testing storage vMotion or cloninig  ensure to explicitly specify Thin Provision.

Test Environment Preparation


“Vdbench is a disk I/O workload generator to be used for testing and benchmarking of existing and future storage products.”

Vdbench User Guide.

Vdbench, widely adopted, cross-platform, flexible benchmarking tool has been utilized to create the workload for this test. Vdbench supports master/slave model. The master node passes the test parameters, initiates the test, and collects the results from participating slave nodes. This test execution method provides a centralized control location and allows for simultaneous test execution on multiple slave nodes. The master node communicates with slave nodes over the network and requires that each slave node runs VDBench listener.

Vdbench ( and Vdbench GOKIT, available at were deployed to generate the test workload.

Master Node

A single Windows 2016 Server virtual machine with 32 GB of memory, 100 GB disk, private test network connection was deployed as the master node. To prepare the master node follow steps below:

  1. Install Java Runtime Environment –Java 8 Update 151 (64-bit) -  download from
  2. Install VDBench – extract the content of the downloaded zip file to c:\vdbench directory
  3. Install GOKIT – extract the content of the downloaded zip file to c:\vdbench\go kit directory
  4. Disable firewall
c:\windows\system32\netsh advfirewall set allprofiles off

5. Verify that VDBench is functional

c:\vdbench\vdbench -tf

 Vdbench ignores lines beginning with * (asterisk) in configuration file.

6. Modify the following Vdbench GOKIT configuration files based on the GOKIT documentation and your environment:

 c:\vdbench\vdbench gokit\global_general_definition.vdb – this file defines data reduction parameters

*Global General Definition section

 c:\vdbench\ vdbench gokit\global_host_definition.vdb – this file defines the slave hosts (VMs) generating workload

*Global Host Definition section
* DS01
* hd name for the slave node (label), system=IP_address or hostname of the slave node

 c:\vdbench\ vdbench gokit\global_storage_definition.vdb -  this file defines which disk or file system will be used for testing; required files are automatically created

* Global Storage Definition section
* 50GB e:\vd-fb-nfstest.pdf file will be created

 c:\vdbench\gokit\global_workload_definition.vdb – this file defines the workload parameters

*Global Workload Definition section
*Storage Workload Defaults

● c:\vdbench\gokit\global_run_definition.vdb – this file defines global run setting

*Global Run Definition section
rd=rd1,wd=wd1_*,iorate=400, elapsed=3600,interval=30

● Create workload_fb.vdb file and place it in c:\vdbench\vdbench go kit directory

*Load Other Configuration Files

● Copy and rename c:\vdbench\vdbench gokit\run_vdbench_1_cluster.bat giving it a meaningful name, for instance run_vdbench_1_fb.bat.

VDBench test results will be placed in c:\vdbench\vdbench gokit\reports\fb\2DS_maxIOPS_16VMs directory. The 2DS_maxIOPS_16VMs subdirectory will be automatically created but all the parent directories must exist before the test is started.

set hr=%time:~0,2%
set hr=%hr: =0%
set start_time=%date:~-4,4%%date:~-10,2%%date:~-7,2%_%hr%%time:~3,2%%time:~6,2%
start /WAIT "FlashBlade" cmd /c ..\vdbench -f workload_fb.vdb -o reports\fb\2DS_maxIOPS_16VMs

 Slave Nodes

The 128 slave virtual machines were deployed from customized templates. Each slave VM upon boot executed three simple batch scripts to enable auto logon (registry setting), disable firewall, and start Vdbench listener.

Virtual Machine Configuration

The Windows 2016 Server virtual machines were configured with four virtual CPUs, 16 GB of memory, single E1000E NIC, two SCSI controllers (LSI Logic SAS, VMware Paravirtual) and two disks:  100 GB drive c:\ and 50 GB data drive e:\ . The 50 GB data disk e:\ was attached to the VMware Paravirtual SCSI controller. Both disks resided on the same NFS datastore. A dedicated network interface for master/slave communication was connected to a dedicated Virtual switch. VMware Tools were installed on all virtual machines.

Virtual Machine Template Preparation

The slave nodes require Vdbench and optionally Vdbench GOKIT. To install Vdbench follow steps 1 and 2 in the master node section. All slave nodes must be running VDBench listener. There are many methods to have the listener automatically started. For this test a simple batch file was created which:

  • modified the registry to enable Auto Logon
  • disabled Windows firewall
  • started the Vdbench listener

This batch file was executed automatically every time Windows Server was booted. The Windows virtual machine was then converted to a template for cloning.

1.Enable Auto Logon – see Figure 23.

a) As a user with administrative privileges launch registry editor:  regedit.exe

b) Locate HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon branch

c) Modify or add the following keys

i. AutoAdminLogon=1

ii. DefaultUserName=Administrator

iii. DefaultPassword=<AdministratorPassword>

iv. DefaultDomainName<DomainName>

v. DefaultDomainName value may be empty if local logon is used.

2. Restart the virtual machine –  the server should log you in as administrator


Figure 23

3. Export the registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon branch to a file - see Figure 24.

a) Select the branch HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon

b) Select File➤Export

c) Verify that Selected branch radio button is selected

d) Provide the file name – this file will be used to import registry settings upon the boot on all slaves


Figure 24

4. Create a batch file:

@echo off
REM Import registry branch to enable AutoLogon
C:\windows\regedit.exe /S c:\<location_of_registry_file\name_of_registry_file>
REM Disable firewall
c:\windows\system32.netsh.exe advfirewall set allprofiles off
REM Start vdbench listener (remote shell)
c:\vdbench\vdbench.bat rsh

5. Launch Group Policy Editor (gpedit.msc) and define the startup script - see Figure 25.

Local Computer Policy-➤Windows Settings➤Scripts(Startup/Shutdown) Startup➤Add➤Browse: select the script created in step 4.


Figure 25

6. Reboot virtual machine

7. Verify Windows firewall is turned off - see Figure 26.

C:\Windows\system32\netsh advfirewall show allprofiles


Figure 26

8. Verify that VDBench listener has started and TCP port 5560 is open

a) Execute netstat command - see figure 27.

netstat -an | Select-String 5560


b) Open Task Manager to verify that Java Platform SE binary process is running – see Figure 28.


Figure 28

9. Execute a simple test from the master node using a single slave node (modify c: \vdbench\gokit\global_host_definintion.vdb file) – see Test Environment Preparation          section

The test results will be collected on the master node in a directory defined in run_vdbench_1_fb.bat. Examine summary.html and logfile.html for errors. If there are no errors, the slave virtual machine should be converted or cloned to a template and can be used for slave provisioning.

Template Creation

From the vSphere Web Client select the virtual machine to be converted or cloned to template. See Figure 29 and Figure 30.


Figure 29

BEST PRACTICE: Create multiple templates and place them on different datastores to parallelize the virtual machine provisioning (cloning) process


Figure 30

Virtual Machine Provisioning (slaves) 

The virtual provisioning process can be initiated manually from the vSphere Web Client, or VMware PowerShell CLI, or can be scripted. Care must be exercised when deploying virtual machines to correctly select the desired datastore for the vm placement. The meaningful virtual machine naming and IP addressing schemes need to be developed to help manage and troubleshoot the test bed.

Each slave node will require a unique IP address and hostname and depending on the existing environment the IP address may be assigned statically or dynamically (DHCP). For this deployment, static IP addresses have been used and a sample PowerShell script and corresponding IP address file are included in Appendix C.

Test Methodology and Execution

The tests were executed Vdbench with the following parameters:

  • I/O Rate: variable
  • Average IO Size: 27 KB
  • Compression Ratio: 3:1
  • Read Percentage: 20, 66, 80
  • Unique Data: 15 GB
  • IO Pattern: Random
  • Test Execution Interval: 3600 seconds (1 hour)
  • Data Collection Interval: 30 seconds

The average IO size of 27KB has been empirically selected based on all Pure Storage production arrays by average IO size with the following distribution – see Figure 31.


Figure 31

Testing Procedure

All tests were started on the master node by executing the batch file created in step Test Environment Preparation/Master Node.

PLEASE READ: with the large number of slave virtual machines it may be necessary to divide and start the test into separate batches

Under some circumstances, when executing tests with large number of slave virtual machines, the master node fails to connect to some of the slaves. As a workaround, it may be necessary to initiate the test by starting two instances of Vdbench on the master node. Simply, copy the c:\vdbench directory and its subdirectories to another location on the same server, modify the test parameters (divide the number of hosts –  see global_host_defiinition.vdb file) and execute the startup scripts from different directories.

The tests were executed in four groups.

Group 1:  128 virtual machines, 100 IOPS per VM, variable read – write ratio.


Read/Write [%]

Number of VMs

IO/s per VM

Total IO/s

















Group 2: 128 virtual machines, 200 IOPS per VM, variable read – write ratio.


Read/Write [%]

Number of VMs

IO/s per VM

Total IO/s

















Group 3: 128 virtual machines, 400 IOPS per VM, variable read – write ratio. 


Read/Write [%]

Number of VMs

IO/s per VM

Total IO/s

















Group 4: 66/34 percent read/write ratio, 400 IOPS per virtual machine, variable number of virtaul machines.


Read/Write [%]

Number of VMs

IO/s per VM

Total IO/s
































Test Results

Groups 1, 2, 3

With 128 virtual machines and varying IO rate (IO/s), FlashBlade exhibited consistent throughput and I/O latency regardless of the workload read/write mix.

For each test group, doubling the number of virtual machines resulted in doubling the FlashBlade’s bandwidth with array maintaining consistent latency – see Figure 32.


Figure 32

Group 4

The FlashBlade throughput scaled nearly as a linear function with steady latency as the number of virtual machines and generated IO/s increases with fixed read/write ratio – see figure 33.


Figure 33

The Performance section in Analysis dashboard on FlashBlade during the sample testing is shown in Figure 34.


Figure 34


The test results show that as the workload and the number of virtual machines increase FlashBlade maintains high throughput coupled with excellent, nearly linear scale-out characteristics. As the customer’s environment expands, it is safe to predict that FlashBlade will deliver consistent and robust IO performance. Additionally, the multiple chassis online expansion without the need for manual data redistribution combined with exceptional scalability makes the FlashBlade an ideal storage device for high bandwidth, high demand virtual environments capable of supporting large number of virtual machines and ESXi hosts with minimal administrative overhead and seamless storage capacity and performance growth.


Appendix A

VMware supports several load balancing algorithms for virtual switches:

  1. Route based on originating virtual port – network uplinks are selected based on the virtual machine port id - this is the default routing policy
  2. Route based on source MAC hash – network uplinks are selected based on the virtual machine MAC address
  3. Route based on IP hash – network uplinks are selected based on the source and destination IP address of each datagram
  4. Route based on physical NIC load – uplinks are selected based on the load evaluation performed by the virtual switch; this algorithm is available only on vSphere Distributed Switch
  5. Explicit failover – uplinks are selected based on the order defined in the list of Active adapters; no load balancing

The route based on originating virtual port and route based on source MAC hash routing teaming and failover policies require virtual machine to vSwitch connection therefore, they are not appropriate for VMkernel Virtual switches and NFS datastores. The Route based on IP hash is the only applicable teaming option.

Route based on IP hash load balancing ensures the egress network traffic is directed through one vmnic and ingress through another.

The route based on IP hash teaming policy also requires configuration changes of the network switches. The procedure to properly setup link aggregation is beyond the scope of this document. The following VMware Knowledge Base article provides additional details and examples regarding EtherChannel / Link Aggregation Control Protocol (LACP) with ESXi/ESX and Cisco/HP switches configuration:

Changing network load balancing policy – see Figure A1 and Figure A2.

To change network load balancing policy using vSphere Web Client:

  1. Select Host (tab)➤Host➤Configure-➤Virtual switches
  2. Select the switch➤Edit (Pencil)
  3. Virtual switch Edit Setting dialog➤Teaming and failover➤Load Balancing➤Route based on IP hash

To change network load balancing policy using command line:

esxcli network vswitch standard policy failover set -l iphash -v <vswitch-name>


esxcli network vswitch standard policy failover set -l iphash -l iphash -v vSwitch1


Figure A1



Appendix B

The typical Ethernet (IEEE 802.3 Standard) Maximum Transmission Unit is 1500 bytes, however larger MTU values are also available. Both FlashBlade and ESXi provide support for jumbo frames with MTU of 9000 bytes. To enable jumbo frame on FlashBlade and ESXi host follow steps below, for the switch configuration consult the switch’s manufacturer documentation.

FlashBlade Configuration

1. Create subnet with jumbo frame – see Figure B1.

a)  Command Line Interface (CLI):

  puresubnet create --prefix <subnet/mask> --vlan <vlan_id> --mtu <mtu> vlan_name


puresubnet create –prefix –vlan vlan2064

2. Graphical User Interface (GUI) – see Figure B1.

a) Select Settings in the left pane

b) Select Network and ‘+’ sign next to “Subnets”

c) Provide values in Create Subnet dialog window changing MTU to 9000

d) Click Save

3. Change an existing subnet MTU to 9000

a) Select Settings in the left pane

b) Select Edit Subnet icon

c) Provide new value for MTU

d) Click Save


Figure B1

ESXi Host Configuration

Jumbo frames need to be enabled on per host and per VMkernel switch basis. Only command line configuration examples are provided below.

1. Login to the ESXi host

2. Modify MTU for the NFS datastore vSwitch

  esxcfg-vswitch -m <MTU> <vSwitch>


esxcfg-vswitch -m 9000 vSwitch2

3. Modify MTU for the corresponding port group

esxcfg-vmknic -m <MTU> <portgroup_name>  


esxcfg-vmknic -m 9000 VMkernel2vs

4. Verify connectivity between the ESXi host and the NAS device using jumbo frames

vmkping -s 8784 -d <destination_ip>


vmkping -s 8784 -d

The -d option disables datagram fragmentation and -s options defines the size of ICMP data. ESXi does not support MTU greater than 9000 bytes, with 216 bytes for the header, the effective size should be 8784 bytes.


Appendix C

A sample PowerShell CLI script to provision multiple virtual machines using template.

# Connect to vCenter server
Connect-VIServer -Server <vCenter_IP_address> -User <”user_name”> -Password <password>    
# Define the naming convention for the virtual machines.
$vmNameTemplate = "d1{0:D3}"
# write-host $vmNameTemplate
# Save the cluster in which the virtual machines should be created into a variable.
$cluster = Get-Cluster fb
# Save the template on which the virtual machines should be based into a variable.
$template = Get-Template w2k16_1
# Create the virtual machines.
$vmList = @()    
for ($i = 1; $i -le 4; $i++) {
    $vmName = $vmNameTemplate -f $i
    $vmList += New-VM -Name $vmName -ResourcePool $cluster -Template $template -VMhost "" -Datastore "DS01"
# Save the static IP addresses from the stored CSV file into a variable.
$staticIpList = Import-CSV C:\vms\1wlist.csv
# Create the customization specification.
$winSpec = New-OSCustomizationSpec -Name wdeleteme1 -Workgroup pure -NamingScheme VM -OSType Windows -FullName Administrator -Orgname pure -ChangeSid:$true -AdminPassword "Osmium76!" -TimeZone 004
# Clone the customization specification to a nonpersistent type.
$specClone = New-OSCustomizationSpec -Spec $winSpec -Type NonPersistent
# Apply the customization specification to each virtual machine.
for ($i = 0; $i -lt $vmList.Count; $i++) {
    $ip = $staticIpList[$i].IP
    $nicMapping = Get-OSCustomizationNicMapping -OSCustomizationSpec $specClone
    $nicMapping | Set-OSCustomizationNicMapping -IpMode UseStaticIP -IpAddress $ip -SubnetMask "" -DefaultGateway "" -Dns ""
#$nicMapping | Set-OSCustomizationNicMapping -IpMode UseDhcp
    Set-VM -VM $vmList[$i] -OSCustomizationSpec $specClone -Confirm:$false
    # New-HardDisk -VM $vmList[$i] -Datastore Vol01 -CapacityGB 20

A sample IP address list file for virtual machine assignment: