I am currently writing some orchestration software for Hyper-V 2012 R2.
The orchestration platform as a whole also talks to other Hypervisors, like Xen. I am in the process of introducing new SAN storage and, due to some desirable features that exist at a storage level, I want to use a LUN-to-VM mapping on all Hypervisors.
I am having real issues with managing this volume of iSCSI connections on Windows. But not in the way I thought I would...
I had heard that there were scaling issues with Windows and ‘lots of LUNs’, but I wanted to check for myself. I am seeing none of the issues other people have mentioned. For instance, I can enumerate 500+ LUNs via diskpart in a second. I can list all connected disks with ‘get-disk’, in under a second, the issue comes from iSCSI scaling itself.
If anyone has a moment to read on, perhaps they could shed some light on why...
I have no issue programmatically connecting to the iSCSI targets, but I seem to have real issues when I start trying to get session information (which I need to get other information).
i.e. There seems to be no way to specify which disk number\address an iSCSI target receives at the point it is connected (unless i'm mistaken). I can work backwards from the IQN via WMI, via a call to
MSiSCSIInitiator_SessionClass
When you start talking about 100+ connected volumes, a call to this class can sometimes take over 10 minutes to return. If I test it via Powerhell with something like:
$query = "Select * from MSiSCSIInitiator_SessionClass Where TargetName='$iqn'"
Get-WmiObject -Namespace "root\WMI" -Query $query
...you can see it get stuck midway through enumerating the volumes. It will pause. I haven’t run the exact numbers, but every additional volume seems to put about 3-4 (or more) seconds on the total time a query takes to return.
It gets a bit weirder. Windows 2012 has some built in iSCSI commands. I can get a connected iSCSI target object in under a second with
Get-IscsiTarget –nodeaddress blah
I can get an iSCSI connection object using
$iscsi_target_object | Get-IsciConnection
... all in in under a second. These must be related to iSCSI session inforation in some way.
A call, no matter how I package it, to Get-IscsiSession takes about 10 minutes to return.
The Hyper-VM manager GUI is also terribly slow when opening the settings page for a VM, presumably because it is enumerating possible pass-through disks via their iSCSI session. This also takes around ten minutes.
A query to Msvm_DiskDrive in root/virtualisation also takes an age to return..
Again, diskpart, Get-Disk etc all return in seconds. I can refresh all iSCSI targets on the system in about a minute with 500+ targets. I thought that was going to be the hard bit.
So, I have two questions.
First all, does this sound right? Is there anything at all I doing something that might impact the speed at which WMI calls are returned? Can I speed WMI up at all?
Secondly, can anyone think of any other way – other than the MSiSCSIInitiator_SessionClass – that I could derive a disk number from an IQN? This might solve the bulk of my problems. Perhaps there other routes to this information i might have missed.
Cheers.