One of the biggest features that was included within vSphere 6.0 has to be that of Virtual Volumes (VVOLs). VMware had been talking up VVOLs as far back as VMworld 2011, since then pushing out 4 new releases of vSphere – but it wasn’t until February of 2015 when VMware announced vSphere 6 that they could finally say that VVOL support has arrived.
The hype around VVOLs is validated – To put it bluntly they simplify the life of the vSphere Administrator. Instead of engaging the storage team to deploy LUNs and datastores the vSphere Administrator can simply now apply a storage policy to a VM, specifying capabilities and requirements around snapshotting, dedupcation, raid level etc – the policy then talks to the storage array and places the VM on the disks that can fulfill that policy. On the flip side, the storage administrators no longer have tune different LUNs and disk groups to meet requirements set forth by the virtualization team – they simply allocate storage which can be consumed by VVOLs.
VVOLs really has only two main requirements
- You need to be running vSphere 6.0 or higher
- Your storage array needs to have built in the support for VVOLs
Even though there are only two requirements one could say that they are pretty big ones – Firstly you may not have upgraded to vSphere 6 yet in production, thus eliminating the ability to deploy VVOLs. For those with home labs – although they may already be running vSphere 6, they may not have access to an array which supports VVOLs – so that is out as well.
This is where StarWind Virtual SAN comes into play. Although it wasn’t’ till 2011 when they rebranded to the Virtual SAN name, StarWind had been providing their software based iSCSI shared-storage solution for quite some time. The software runs on Windows, and supports a lot of the features that you might find in comparable physical arrays. Features such as Caching, High Availability, Fault Tolerance, Scaling characteristics, deduplication, compression, replication and snapshots are all built into StarWinds Virtual SAN offering. Another feature (which is currently in Technical Preview) as you may have already guessed is VVOL support! This means we don’t need expensive arrays in order to try out VVOLs, we can simply use a Windows server with some attached local storage and StarWinds’ Virtual SAN.
How to get started with StarWind VVOLs
The first thing you will need to do is download the technical preview of the StarWind VSA, or Virtual Storage Appliance. The VSA is the easiest and quickest way to get StarWind Virtual SAN up and running as it contains the complete installation (180 day trial) of Windows Server, pre-loaded and configured with StarWind Virtual SAN. All you need to do is deploy it and attach it to your proper networks. You can download the latest version of the VSA (with VVOL support) here. Due to Microsoft licensing you will find that the VSA comes as a preconfigured VM for Microsoft Hyper-V, however if you want to use it with vSphere (as I did) it also handily comes packaged with the StarWind V2V converter which will allow you to convert the vhdx files into vmdks for deployment to ESXi.
Since StarWind utilizes iSCSI as it’s transport method you must set up iSCSI initiators on your ESXi hosts. If you already have configured hardware or software initiators you can go ahead and use them, just ensure network on the VSA is on the same subnet. If you haven’t I’ll explain the process below…
The first thing we will need to do in order to connect our hosts to the VSA through iSCSI is to setup some basic networking. Follow the ‘Add Host Networking’ wizard using the following options…
- Connection Type – VMkernel Network Adapter
- Target – New Standard Switch
- Physical NICs – any free physical NIC that is connected to the storage network
- None of the services will need to be enabled
- Give your VMkernel a proper IP and subnet in order to reach the StarWind VSA storage network
Once the networking is setup we need to enable your software iSCSI imitator on your host. From the Manage-Storage tab within the vSphere Web Client click the ‘+’ icon while on the Storage Adapters section to add the iSCSI initiator. From that same screen select your newly added iSCSI adapter and then select the Network Port Binding tab. Here is where we will bind our imitator to the vSwtich we created earlier. Click the ‘+’ icon and bind the adapter to the proper VMkernel network as shown below…
Once completed we can go ahead and add the StarWind VSA as a target within our initiator – again, this is done in the storage adapter section, but on the ‘Targets’ tab as shown below…
Give the host adapters a quick storage rescan to allow them to connect to the StarWind VSA. Once the StarWind VSA and the ESXi hosts have been configured its finally time to dive into the setup for VVOLs. VVOLs relies on VASA 2.0 in order to allow for communication between vCenter and the Storage Arrays. Thankfully configuring this is as simple as passing a url and some credentials to vCenter.
But before we get too deep there are some commands we may need to run depending on how your environment is setup – You may need to rebind the MAC on the StarWind VSA to its corresponding certificate. For instance, if you are planning on connecting the StarWind VSA via IP address (such as I did below) then you should run the following command on your StarWind VSA to reset the VASA certificate.
wmic -namespace:\\root\starwind path STARWIND_ClusterService call ResetVASA BindToInterfaceMAC=<MAC ADDRESS>
Keep in the mind the MAC address that you want to place in the above command would be the MAC address of your VSA’s management interface.
With that out of the way it’s time to register our StarWind VSA as a storage provider within vCenter. From the Manage tab with the target vCenter server in context, select the Storage Providers section and then “Register a new Storage Provider”. From here we need to provide the StarWind VASA URL (https://<IP_OF_StarWind>:9991/vasa/) and the default username and password (root/starwind) as shown below…
With our Storage Provider registered and our target server identified we now have a couple of the building blocks in place in order to use VVOLs – the last thing we need to do is configure VVOL datastore – essentially a container that we place our VM disks on within vCenter, which will in turn instruct the array to create its own VVOLs. Adding a VVOL datastore is similar to the process as adding a regular vmfs datastore, only selecting VVOL as the storage type as shown below.
From there the only other requirement is selecting the StarWind array as the backing storage container. If all of the steps were performed properly you should see it appear as a valid backing storage container as shown below…
Once this is done we can start playing around with VVOLs and the StarWind implementation of them. For instance, by creating a new VM and selecting our VVOL datastore as the storage we can see that instead of the traditional files being placed within an image file inside of Starwind, that new image files are created – one for the configuration of the VM, and another for the disk of the VM (see below)
The creation of the ImageFiles is done by StarWind and it is automatically processed providing you pick your VVOL datastore as your storage target. Shown below we can see how things change once we power on our VM, again, another image file is created, this one holding the storage for the swap file. When the VM is powered off this ImageFile will be automatically deleted.
At this point we can confirm that VVOLs are indeed working the way we expected them to – instead of a VM residing inside files on top of a LUN, the components of the VMs are essentially each their own LUN. This is some great technology that will definitely change the way we deploy storage; however we aren’t done yet – we still need to look at a little concept called VM Storage Policies.
VM Storage Policies is a concept that basically allows us to define policies – these policies in turn dictate how we utilize different features and components that the array provides. These policies are then attached to VM disks, and will automatically place the disks of the VM on the proper chunk of storage depending on the policy requirements. Take the below image for example, we can define a new policy that will define whether we would like the disk to be deduplicated, thin provisioned, replicated, as well as the array caching requirements. These capabilities are all provided and performed by the StarWind VSA.
To create a VM Storage Policy it’s a matter of clicking ‘Policies and Profiles’ –> VM Storage Policies and selecting to ‘Create a new VM storage policy’. We then define our rule-sets based on the characteristics of storage we want. Creating the policy is only half the work however – we still need to assign the policy to our VM.
As you can see above this is done within the ‘Add New VM’ wizard. When on the ‘Select Storage’ step instead of simply selecting our VVOL datastore as we have done previously we assign a VM Storage Policy to the VM. In the example above we selected ‘Gold’ and we can see that our VVOL datastore that we created earlier is indeed compatible with that policy – meaning it meets the requirements that we defined within the policy’s rulesets. Also, as shown below we can assign different storage policies on a per disk basis within the VM. This allows us to support use cases such as a backup drive. Maybe we have one storage policy dictating faster disks to host our OS VVOLs, and another that defines slower disks such as Nearline for our backup drives. Either way we can mix and match policies per VM.
So as you can see you don’t need to purchase expensive hardware if you are just trying to get a look and feel for VMware and VVOLs. The technical preview of the StarWind VSA will give you most, if not all the functionality you need to get a feel for how things are going to work, using existing local storage you already have in place. Certainly StarWind is not done with their VVOL implementations either, they are constantly providing updates to the Technical Preview for you to check out – watch for things such as snapshot support, etc coming in the near future. For now, get a head of the game and get the technical preview up and running for yourself so you can see what all the VVOL hype is about!
Hi,
Thanks for the detailed explanation. I have successfully deployed Starwind VSA in my ESXi. As you have mentioned it is Windows 2012 server with Starwind Virtual SAN V8 build is installed as Setup. Nothing else i could find.
I have few queries for you.
1. Are Tomcat and VASA setup residing this VSA application itself? Since https://localhost:9991/vasa/ is not working.
2. I thought i could be due to certificate issue and hence I tried your command. But it is failing below.
C:UsersAdministrator>wmic -namespace:\rootstarwind path STARWIND_ClusterService call ResetVASA BindToInterfaceMAC=##-##-##-##-##-##
Invalid Verb Switch.
Kindly help me to proceed further.
Regards
Karthik K
http://karthikksamy.com