Wednesday, October 15, 2014

How to Configure a Cisco UCS to Use a Single IQN for a Boot LUN on Path A and B

Hi Friends,

Got a cool new feature I wanted to share with you that will help simplify things in your UCS and Nimble when you are booting from iSCSI.  Pre UCS Manager 2.2, when you were setting up a service profile which would iSCSI boot, you set your iSCSI boot parameter for each iSCSI vNIC to draw from an iSCSI pool and each would grab their own IQN.  As you can see below, here's my iSCSI-Boot-A for one of my service profiles that has not been changed.  It has individual initiators for both A and B.

Is this a bad thing?  No, not at all, but it can get confusing when you have a lot more than one service profile, you have a ton of IQN's and you think to yourself, "Does this IQN come from profile 1 or 100?"

So here's a way you can cut your boot IQN's in half.

WARNING - This will cause a reboot of the server bound to your service profile if you're changing to single IQN!
WARNING - If you're unfamiliar with UCS don't attempt this on your own, talk to your UCS Administrator for help!

1.  Click on the root of your service profile, click on the iSCSI vNICs tab and select Change Initiator Name.

2.  A Change Initiator Name box will pop up, select the IQN pool that you've been drawing from for IQNs.  If you're unfamiliar with this you probably want to talk to your UCS administrator.

3.  You'll get a new pop up that tells you what you've done and that a reboot is necessary.

4.  Once your server has rebooted, click on the root of the service profile again and the iSCSI vNICs tab.  You'll notice the Service Profile Initiator Name is now populated with your IQN pool and a common initiator for your boot vNICs.

5.  Remember, the IQN for your service profile has just changed, it will need to be modified wherever you used it.  For example, your Nimble, vCenter, etc.  Below is an initiator group on the Nimble that has both the original IQNs in it.  They will need to be removed and the new single IQN added.

Note:  You'll probably want to wait to remove the old IQNs until whatever you're booting comes back.  If you delete them before the boot happens, whatever is booting doesn't know about the new single IQN and may not boot if you remove the original IQNs before it has a chance to come back up.

This will help cut down on the number of IQNs you have to create and use, plus it will help with housekeeping and will hopefully keep things less complicated in your environment.

Until Next Time!


  1. Hi,
    I can't find any powershell (powertool) cmdlet to set manual (not Pool) IQN on SP like you did on GUI. Do you have any idea if it exist?

  2. Hi Muson,

    The commandlets to do this type of activity appear to be half-way implemented. They really don’t work yet. Here are the ones in question.

    Now that being said.. you can almost do this using an XMLtag operation… But not quite…. The commandlet completes, but if you look at the UCSM, it does not change the initiator.
    set-ucsmanagedObject -XmlTag vnicIScsiNode -PropertyMap @{ Dn ="org-root/org-ESX-Cluster/ls-esx-host1"; InitiatorName="";}

    InitNameSuffix :
    InitiatorName :
    IqnIdentPoolName :
    OperIqnIdentPoolName :
    Owner :
    Dn : org-root/org-ESX-Cluster/ls-esx-host1
    Rn : ls-esx-host1
    Status : modified
    XtraProperty : {}
    Ucs : FI-A

    What I have had success in doing is to assign an associated pool to a template or Service Profile. While this doesn’t give you a specific IQN, it will at least assign it to a iqn pool.
    $template_dn = “org-root/org-ESX-Cluster/ls-esx-host-Nimble-SANboot”
    $iqn_pool_name = “org-root/org-ESX-Cluster/ls-esx-host1”
    add-ucsmanagedObject -XmlTag vnicIScsiNode -PropertyMap @{ Dn = "$template_dn"; IqnIdentPoolName = $iqn_pool_name; }

    Thanks and regards,
    Steve Sexton