Many of you (thousands, impressively!) read the three articles that Mitch Garvis wrote in April about Microsoft’s Software iSCSI Target 3.3. If you didn’t, you can read them all now by clicking below:
In the months since, and more recently as both Mitch and I have been delivering IT Virtualization Boot Camps (register for Montreal, and Saskatoon now) a lot of people have asked us if this would work with Microsoft Hyper-V Server, and if so… how? The answer, of course, is YES it will work, but as with all things command-line, you cannot simply rely on the GUI and as such, there is another layer of complexity involved. Mitch outlines the steps you will need to follow to be able to configure your Hyper-V Servers (as well as your Windows Server Core boxes) as nodes in a failover cluster.
In the Server Core and Hyper-V Server Server Configuration menu there is an option (number 11) to enable the Failover Clustering Feature. This takes a few seconds, and you are off to the races. You will also have to use Option 4 to Configure Remote Management; although I am sure it is all configurable by command line, I would much rather create my Failover Cluster using the Failover Cluster Manager. You can do this either from a server with the Failover Clustering feature enabled, or from a system with the Remote Server Administration Tools (RSAT) installed. That server does NOT need to be a node of the cluster.
Unfortunately before you proceed with all of that great and simple GUI driven stuff, we have to present your iSCSI target to the Hyper-V Servers. This we will do locally from the command line:
1) Start the Microsoft iSCSI Initiator Service:
net start msiscsi
2) Configure the Microsoft ISCSI Initiator to start automatically when you start up:
sc config msiscsi start= auto
(note the space after the = sign. that is intentional and required)
3) Connect to the Target and set up a persistent login to same:
iscsicli QAddTargetPortal 172.16.10.5
(note the address I used is the IP address of the server that is running the iSCSI Software Target)
iscsicli ListTargets
We see here that I have a single target available to me, with the IQN (Internet Qualified Name) of iqn.1991-05.com.microsoft:swmi-storage-target1-target – which shows that my SAN provider is Microsoft, that my server is called swmi-storage, and that my target (LUN) is called Target1 (I have a great imagination for names).
iscsicli QloginTarget iqn.1991-05.com.microsoft:swmi-storage-target1-target
This logs my server in to the target that was listed.
iscsicli PersistentLoginTarget <target_iqn> T * * * * * * * * * * * * * * * 0
This will make sure that the login is persistent – whenever you reboot.
iscsicli ListPersistentTargets
This will confirm that your target is persistent, and will list:
- Target Name
- Address and Socket
- Session Type
- Initiator Name
- Port Number
- Security Flags
- Version
- Information Specified
- Login Flags
- Username
Admittedly, much of the information found therein will not be helpful. However it will determine that your target is persistent.
iscsicli ReportTargetMappings
In this screenshot you can see the session ID, Target Name, Initiator, Initiator SCSI device, Initiator bus, target ID, and target LUNs – in this case, there are four LUNs.
Now that you have presented your target (or targets) to the servers you are ready to continue remotely with the GUI… the easy part, which you can review in the blogs posted up top.
Remember, managing your servers via command line may be daunting, but it pays off. Not only does it usually give us better control over what we are doing, but by using Server Core (or Hyper-V Server) you can take back a lot of resources that would otherwise be wasted on the GUI.
Have fun and have a great week!
