Does a Host need to access a Boot LUN after the initial boot?

[rossanderson]

Configuration - Cisco UCS, vSphere 6, iSCSI Boot

As part of a recent storage migration, 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).

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. 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 no iscsi connections to the boot vol once boot-up is complete), but maybe I'm just missing something?

Any thoughts? Thanks in advance!

[Techie01]

I have tried the experiment of booting esx using USB and then after the boot, remove the USB from the server. ESXi continues to work.

But this also means that, you will not have access to persistent log directory, support bundle generation location, vmware tools repository etc. If you have all these location in a different place , then AFAIK, there is no impact . Obviously during reboots the configration changes need to be flushed back on to disk and lack of access to boot disk will cause issue at that time

[rossanderson]

Thanks for the feedback. I, too, haven't seen any issues so far using this method. However, I don't know of any other way to isolate the Boot VOL/LUN from the host so that it can't accidentally be used for a datastore. I was under the impression that it was best practice to somehow isolate the host from the Boot LUN .. I'm just worried about any future fallout or issues now that the Host can no longer access the boot lun.

[efanjo]

Hi,

if you choose a small boot lun, like the minium required size, you can not create any datastore on these luns.

See storage requirements: Best practices to install or upgrade to VMware ESXi 6.0 (2109712) | VMware KB

Then only a user with direct access to the host can use/see this lun.

[rossanderson]

Thanks - what I've decided to do is share the Boot Lun only for the initiator name of the UCS Blade/VMware host that needs it. That way, each host can only see it's OWN Boot lun, so if you ever see a 5gb LUN, then you know that's the boot LUN for that PARTICULAR host that you are on currently. I'm using a different initiator group for the datastore volumes that contains ALL of the host initiator names, so then vMotion reqts will be satisfied without giving Boot LUN access to all Hosts .. only the one that needs it. This isn't a perfect solution but it mitigates the majority of the risk.

Thanks for the input, everyone. Rgds