It is only several days since Microsoft made the final bits of System Center 2012 SP1 available, although for a relatively limited audience. If you have a TechNet or MSDN subscription, you have access to SP1 now. All others have to wait till general availability in the course of January 2013.
One of my fellow MVP’s in the Cloud and Datacenter Management department, Graham Davies, raised my interest by claiming there was something in VMM 2012 SP1 that had gone unnoticed: a brand-new SMI-S storage provider for the onboard iSCSI Target Server role in Windows Server 2012! People using the iSCSI Target Server for both demo/test/development and production will get quite excited if they discover how well this software storage solution is integrated, not only in Windows but now also in System Center 2012 SP1.
Back in March 2011, I wrote several blogs about the new Fabric concept in Virtual Machine Manager 2012 which was still in its early beta. One blog focused on deep storage integration using a SNIA standard called Storage Management Initiative Specification (SMI-S). When I was contributing my Fabric chapters for the Microsoft Private Cloud Computing book, there was only a limited number of usually very expensive storage arrays to really dig into this subject. I had access to some HP and NetApp storage to test SMI-S integration which was still very limited at the time. When we saw how the iSCSI Target Server, which was previously a separate install on Windows Server 2008 R2, developed and became included as a role in Windows Server 2012, we begged the product managers responsible for storage in System Center 2012 to also provide SMI-S support. Well guys … here it is!
Fast forwarding about two years, a lot has happened in the storage space and most storage vendors have introduced SMI-S support for their most important storage products. I now consider storage that does not support SMI-S (and some of the other cool technology such as ODX and Unmap/Trim), as a sign that these products are on that vendor’s death list and will soon be obsolete.
But let’s get back to the exciting world of System Center 2012 SP1 and storage. In this blog I’ll show you how to integrate servers with the iSCSI Target Server role into Virtual Machine Manager 2012 and what you can do with it.
In case you have not used Microsoft’s iSCSI Target Server before, here is a short introduction:
Microsoft iSCSI Target Server is a feature that enables a Windows Server 2012 server to function as a storage device. VMM 2012 supports the use of block storage devices implemented using the Storage Management Initiative Specification (SMI-S), or using a native WMI storage management provider (SMP). VMM in System Center 2012 SP1 introduces support for the iSCSI Target Server using an SMI-S provider. Note that only VMM in System Center 2012 SP1 can be used to manage the SMI-S provider for iSCSI Target Server described in this topic. For more information, see Introduction of iSCI Target in Windows 2012.
The SMI-S provider is installed on the iSCSI Target Server. In the diagram below you can see how the SMI-S provider, which is WMI-based, interacts with the other components and manages the iSCSI Target Server using the iSCSI Target WMI provider. The SMI-S provider passes information from the iSCSI Target service to the Storage Management service on the VMM server. After the provider has been registered with VMM, the storage array is discovered and all information about its objects and mappings are retrieved from the SMI-S provider.
In the current version we can manage only one WMI based SMI-S provider per machine. If you need to manage multiple storage providers I refer you to the Technet article for further details.
For a reference to Windows Server standards-based storage management also look here:
It is advised to update all Windows Server 2012 servers to at least the November 2012 cumulative update KB2770917 which offers performance and reliability improvements.
Installing Microsoft iSCSI Target SMI-S Provider
First of all we need to install the Microsoft iSCSI Target SMI-S Provider on the Windows Server 2012 iSCSI Target servers we want to manage with VMM 2012 SP1.
iSCSITargetSMISProvider.msi can either be found on two locations:
On VMM 2012 SP1 ISO under path:amd64Setupmsi
On the VMM server under
Program FilesMicrosoft System Center 2012Virtual Machine ManagersetupmsiiSCSITargetProv
Storage Cmdlets in Virtual machine manager 2012 SP1
Let’s first take a look at the System Center storage commands available in the virtualmachinemanager PowerShell module. If you are running this command from the VMM PowerShell Window then the *SCStorage* commands will work without taking any preliminary steps. If you are running the cmdlets from Windows PowerShell ISE (Integrated Scripting Environment), be sure to first load the virtualmachinemanager module.
Registering the iSCSI Target SMI-S Provider with VMM 2012 SP1
We are going to add a provider for an existing Windows iSCSI Target Server to VMM 2012 SP1 with the intention to make its storage easily available for different tasks such as providing LUNs to Hyper-V hosts and guests. Because we get full insight in the storage part of the fabric through System Center we gain end-to-end manageability of storage, right from the VHDX connected to the guest to the storage array, its disk pools, its LUNs and its connections.
The first step we need to take is create a RunAs account for the storage device. We cause we are dealing with a Windows storage server, we can use the domain administrator, but for security reasons we preferably use a regular administrator with access to the local resources of the storage server. The account should at a minimum be a member of the local Administrators group.
You can verify that the RunAs account is creating by navigating to the Settings pane. Expand Security and click on Run As Accounts to see that RunAs_iSCSI_Target account has been created.
We use the Add-SCStorageProvider cmdlet to add the Microsoft iSCSI Target Provider
After this you will be able to see the provider in the VMM GUI in the Fabric pane under Storage | Providers
In our case a new storage device of type StorageArray appears next to two existing Windows Server 2012 SMB 3.0 file servers which also provide storage services to our Microsoft Private Cloud. It stands out by its SmisWmi provider type as compared to WindowsNativeWmi for the SMB file servers.
We can continue to review the attributes of the storage array by using a variable $array and the Get-SCStorageArray cmdlet. It shows many interesting details
Here is another piece of the same output showing the capacity and some of the capabilities. As you can see the iSCSI Target Server does not support Cloning, but it is Snapshot capable and SAN Transfer capable.
The next step is to take a look at available storage pools. Each drive seen by the iSCSI Target Server can be regarded as potential storage to be used in the storage pool.
In our example both the C: and D: drive show up as capacity if we query the StoragePools attribute in $array.StoragePool.
Of course we leave the OS partition free for Windows and use the D: disk as the storage pool for carving out LUNs. Here you can see the currently defined iSCSI Targets which were created before we registered the SMI-S iSCSI Target provider with VMM.
At this point VMM shows the following under Fabric | Storage | Arrays.
Selecting a Storage Pool
Here’s how we select one of the available pools ("iSCSITarget: PCI-ST1: D:") from the iSCSI Target Server for use in VMM.
Adding a Storage Classification
VMM offers a number of storage classifications, which can be seen as labels that explain the type or quality of storage. We could offer Bronze, Silver, Gold, Platinum etc for the different types of storage. In our example we’ll create a Bronze classification for the iSCSI Target Server storage using the New-SCStorageClassification cmdlet.
Adding the storage pool to VMM
Now that we have selected a storage pool in the $pool variable and created a storage classification in the $class variable, we can add the storage pool to VMM.
In VMM the pool shows up under Fabric | Storage | Arrays as a managed pool, displaying both total, used and allocated capacity.
As soon as the storage array has any managed storage, there are plenty of cool things you can do. If you navigate to Fabric | Storage | Classification and Pools you can see all the disks that have already been provisioned.
And if you dive deeper on a disk you can find it’s registered iSCSI initiator addresses. In this example the LUNs are presented to a Windows Server 2012 Scale Out File Server cluster.
Assigning storage pool to VMM Host Group
You can specifically assign storage to a VMM host group, containing one or more Hyper-V, VMware or XenServer hosts or clusters. This also indirectly determines which storage is used by specific clouds which are in turn assigned one or more host groups.
Allocate storage to a host group
Next we need to allocate the storage pool to a host group using the Set-SCStoragePool cmdlet using the $pool variable as its input for the -StoragePool parameter.
Creating and allocate a LUN
From here we can create LUNs using the New-SCStorageLogicalUnit and allocate LUNs with
PRESENTING THE LUN TO CLUSTER NODES
We need to assign the LUN to a Hyper-V cluster with two nodes with the following initiator names:
The PowerShell command to add these LUNs is Register-SCStorageLogicalUnit followed by the name of the LUN and the two iSCSI initiators:
Register-SCStorageLogicalUnit -StorageLogicalUnit $LUN -StorageInitiators @("iqn.1991-05.com.microsoft:pci-hv1.nlpci.lan", "iqn.1991-05.com.microsoft:pci-hv2.nlpci.lan") –RunAsynchronously
The LUN should now surface on both Hyper-V hosts
From here you will find yourself in familiar territory.
In the opposite direction we can of course unpresent the LUNs by this command
Unregister-SCStorageLogicalUnit -StorageLogicalUnit $LUN -StorageInitiators @("iqn.1991-05.com.microsoft:pci-hv1.nlpci.lan", "iqn.1991-05.com.microsoft:pci-hv2.nlpci.lan") -RunAsynchronously
Finally you can remote the LUN or even remove the storage provider
# Delete a LUN
Remove-SCStorageLogicalUnit -StorageLogicalUnit $LUN
# Remove a storage provider
Remove-SCStorageProvider -StorageProvider (Get-SCStorageProvider -Name "Microsoft iSCSI Target Provider")
If you have followed through until here, you will see that a lot of flexibility that already was available in VMM 2012 has been extended by support for the Windows Server 2012 iSCSI Target Server. In our Microsoft Private Cloud Computing book you can find a lot more about the VMM Fabric and SMI-S Storage Integration in particular. If you need to test or demo storage integration, this has become a great deal easier!