Isolate iSCSI Boot LUNs from VMware Host?

[gtranderson132]

Configuration - Cisco UCS, vSphere 6, iSCSI Boot

As part of a recent storage migration to Nimble, I've been reloading hosts and wanted to isolate the BOOT luns so that only the UCS blade can see them (ie. VMware hosts should not see those vols/luns). This is not the default method, because when VMware is first installed (using iSCSI boot on UCS), the vmware iscsi software adapter will take the same initiator name as the UCS blade (iSCSI vNIC). This means that the host will also be able to "see" the boot LUNs, which presents a small risk because someone may accidentally use a boot lun as a datastore (however unlikely). This is the way I have done it in the past, which has been fine really but still presents a small risk.

To address this, I've renamed the host's iscsi software adapter initiator name (aka WWN) so that it's different than the UCS Blade's iscsi vnic initiator name - thus, upon initial boot, the blade can access the Boot lun but since the vmware host now has a different initiator name, it cannot see the boot luns and can only see the datastores assigned to it's own initiator name. Great - it seems to work fine and I'm able to use the host normally and reboot without issues, but I'm just wondering if the VMware host will ever need to access the BOOT LUN for anything after the initial boot.

Has anyone else isolated their boot luns from their vmware hosts? It seems odd that after initial boot, neither the ucs blade nor the vmware host needs to have access to the boot lun (I've verified that there are NO iscsi connections to the boot vol once boot-up is complete - they disappear after the hypervisor fully starts), but maybe I'm just missing something?

Any thoughts? Thanks in advance!

[steves43 · Accepted solution]

Hi Ross,

You will be better off to just have a single IQN for both the UCS boot config and the ESXi configuration.  This is much easier to administer as well as prevent any kind of potential issue with SCSI reservations with multiple initiators.  But you do bring up a valid point of restricting access to the boot volume for a given host.  Instead I would suggest restricting access to the boot and data volumes using multiple initiator groups. 

Let me give an example:

1) From the UCS hardware side, select a single UCS Service Profile level initiator IQN for boot connectivity.

2) On the Nimble Storage target side create an initiator group that includes only the host Service Profile level IQN created above (e.g. esx-host1).

     * Note that this initiator group should NOT have the (allow multiple initiators) checkbox selected.

3) Create a boot volume and map it to the single host initiator group (esx-host1)

4) Create a second initiator group that includes all of your ESXi hosts' initiators. (e.g. ESX-Cluster)

     * Note that this initiator group should have the (allow multiple initiators) checkbox selected

5) Create and map data volumes to use the ESX-Cluster initiator group.

This solution both restricts access to the boot volume to a single host and at the same time allows access to datastore volumes.  For more detailed instruction see: https://infosight.nimblestorage.com/InfoSight/media/cms/active/smartstack_getting_started_guide_iscsi_connectivity.pdf

[gtranderson132]

Thanks Steve - that is effectively what I ended up doing. Thanks for taking the time to reply.

[dbauder92]

I don't know if you got an answer to one of your questions, the one about the host accessing the boot LUN.  Mostly no it will not.  Log files are the only thing that gets written back to the boot LUN.  These can be redirected to a different location (via the host's Syslog.global.logDir Advanced setting) and is the preferred method when booting from USB or SD media.  Just in case you were curious.