A follow-up to my article on configuring iSCSI Initiator in Server Core & Hyper-V Server

There are real advantages to being a veteran of the IT industry… you learn to do something, and it continues to work through version changes; when people discover features in Windows 2008R2 I am often amused to point out ‘Yeah, that’s been there since Windows Server 2003… it’s just never been popular.’

One disadvantage, though, is that sometimes things are made easier, and you overlook them because you learned things the hard way, and there is no need for you to look any further.  Joachim Nässlander (www.nullsession.com) and Sander Berkouwer (http://blogs.dirteam.com/blogs/sanderberkouwer/default.aspx) read my recent article on configuring iSCSI Initiator on Server Core and Hyper-V Server (Server Core, Target, and Initiator- Commanding them to work!) and pointed out on Twitter that iscsicpl.exe (the GUI for the iSCSI Initiator console) is now included in Windows Server 2008 R2 Server Core installations.  I logged into one of my Hyper-V Server 2008 R2 hosts and confirmed that it is included in that SKU as well.

imageWhile I was surprised that it was there, I am also quite pleased.  As a Virtualization Evangelist (not my official title) for Microsoft Canada I am tasked with showing people – IT Pros, User Groups, Partners, and Clients – how to leverage Microsoft Virtualization, and how it really is as simple as I say.  While I hope that Server Core (and Hyper-V Server) stay as lean and mean as possible, I think this was a fair compromise that will make implementing these platforms more attractive to customers… and isn’t that why we build technology?

With all of that being said, the steps laid out in my article still work… and if you are using Server 2008 (or Hyper-V Server 2008) then it is your best way to connect to an iSCSI Target.

I want to thank my MVP peers for pointing this out because aside from proving that nobody knows everything, the knowledge they gave me will help me directly with my clients as well as my demos going forward!

So now that you know, what is your excuse for using the full GUI installation of Windows Server as your host? Smile

Server Core, Target, and Initiator: Commanding them to work!

Many of you (thousands, impressively!) read the three articles that I wrote in April for Microsoft Canada 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 I have spoken with a lot of people who have asked me 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.  By following these steps you will be able to configure your Hyper-V Servers (as well as your Windows Server Core boxes) as nodes in a failover cluster.

image

In the Hyper-V 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

image

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

image

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-end!