vRA - Create LUN and deploy VM

Lately I've been working with a customer who wanted to automate the process of creating LUNs for specific VMs in the deployment process.

Before anyone screams out the infamous "LUNs suck", the customer are in the process of setting up a new environment based on vSAN, but their existing SAN will be used for several years so they want to make the most of it.

Back to the topic. The customer uses vRA for deploying VMs and this is working already, with some extensibility around tagging and DRS group membership.

For that we used an Event subscription connected to a vRO workflow and that was the path we went through in this case also.

High-level Overview

The high-level steps for the process is as follows:

  • User requests a new VM from a vRA Request form
  • An event subscription will fire a vRO workflow
  • The vRO workflow will create a new volume on the storage array with specifics based on the user input. It will also map the LUN and create the VMFS datastore in vCenter
  • After the datastore has been created the workflow will override the datastore property on the requested VM and use the newly created datastore
  • The VM will be deployed on the specified datastore with the other specifics and properties selected from vRA
  • After the provisioning has finished a workflow for creating disk partitions will run


\

Overview


\

So, with the high-level in place let's get into a bit more details.

SAN Automation

First of we checked out the automation abilities on the storage arrays. The customer has DELL Compellent arrays and DELL has a Powershell module available that can be used to work with the array. Sadly there's no vRO plugin.

With the Powershell module in place we created a script that will connect to the Storage Manager (DSM), create a volume with the specified size in a specific volume folder. The script will decide the Storage profile and type as well as the Volume folder based on user input and some standards the customer have defined. The script will also check that there are sufficient disk space left on the array (for multiple tiers).

vRA Event subscription

In vRO we created a workflow that runs this script based on user input. The workflow also fires the process of the creation of a datastore in vCenter and finally it overrides the datastore property in the VM request.

The first workflow will be fired from an Event Subscription. First we used the VMPSMasterWorkflow32.Requested Lifecycle state, but this state doesn't give me the wanted error behavior. This means that even if the workflow for creating storage stuff fails the deployment continues. We changed to the VMPSMasterWorklow32.BuildingMachine and the PRE event which will set the Error state to Disposing if the workflow fails. Check out the docs for more info.


\

Event subscription


\

Remember to include the correct Lifecycle phase names to the Properties of the VM blueprint so the properties will be passed to vRO!

vRO workflows

So this subscription fires the first workflow


\

Workflow


\

The workflow will pull the request properties and then fire another workflow that will run the Powershell script for creating stuff on the storage array.


\

Workflow


\

The last step in this workflow is to create the datastore in vCenter. Here we're using the built-in workflow Library/VMware/vCenter/Storage/Add datastore on iSCSI/FC/Local iSCSI.

After the second workflow is finished the initial workflow will override the datastore names on the request object. We're using the built-in action com.vmware.library.vcac/addUpdatePropertyFromVirtualMachineEntity for this and the property to override is the "VirtualMachine.DiskN.Storage" where N is the disk number to override (starts on 0). In this use case we're actually changing only a subset of the disks provisioned, hence we're going with the datastore determined by the reservation for some of the disks.

At this point everything should be set and the provisioning can continue as normal.

Disk partitioning

The last piece of this process is the OS Disk partitioning on Windows VMs. For this we're using the built-in DiskPart utility in Windows. To kick off the workflow we have another Event subscription in vRA firing on the POST VMPSMasterWorkflow32.MachineProvisioned event. We're also filtering on a specific Blueprint so it runs on only the wanted scenarios.

The receiving workflow will pull the request properties and then call a workflow for copying the partitioning script to the VM.


\

Disk partition Workflow


\

After the file has been copied the initial workflow will set the arguments for the script and run the script that initializes the disk, creates a partition and formats it with the correct filesystem and block size.

 1param($DiskNumber,$DriveLetter,$DriveLabel,$BlockSize)
 2
 3Import-Module Storage
 4$extDisk = Get-Disk -Number $DiskNumber
 5if($extDisk.Operationalstatus -ne "offline"){
 6    throw "Disk $diskNumber is not offline, cannot continue"
 7}
 8Initialize-Disk -Number $DiskNumber -PartitionType GPT
 9New-Partition -DiskNumber $DiskNumber -UseMaximumSize -DriveLetter $DriveLetter | Format-Volume -FileSystem NTFS -NewFileSystemLabel $DriveLabel -AllocationUnitSize $BlockSize
10

Summary

This automation has been quite fun to create with lots of steps involved, and hopefully it can give some ideas to others as well although there are a few parts I would have liked to do a bit better.

First there is at this point no logic for the disposal of the volume if the workflow fails, or if the VM is destroyed from vRA, but this is something that we will look at going forward.

That missing functionality lead us to discussing creating the volume on the storage array as a proper custom resource in vRA allowing for easier Day 2 operations. This however would require more complex set up in vRO as Custom resources works with vRO types through plugins.

There is sadly no plugin for the DELL Storage solution available and we'd have to create the code ourselves. With vRA 8 upcoming we found that the amount of time required for creating something that might not be reused in the next version wasn't worth it. We'll probably revisit this automation when we get the 8.x environment up and running.

Thanks for reading!

This page was modified on December 18, 2019: Fixed description