Planning for Windows iSCSI SAN boot on Private Cloud Bare Metal Hosts
Data Center Modernization has definitely reached critical mass. The message that came from TechEd 2013 was “It’s time to make Hybrid Cloud Real.” That, of course, starts with the modernizing your data center to be able to implement private clouds. On top of that, more and more data centers are migrating their hypervisors to Hyper-V in spite of the greater footprint a full Windows Server operating system has on the bare metal. The feature parity as well as cost savings that comes from Hyper-V as a feature (and the subsequent removal of the VMWare tax) offsets the hassle of the additional footprint.
Windows Server bare metal hosts running Hyper-V, like other hypervisors, support SAN boot of the operating system drive using iSCSI. It is important to realize that the iSCSI services depend on the underlying storage and iSCSI network being provisioned properly to accommodate the eccentricities of how Windows boots from SAN using network interface cards in place of traditional storage adapters or HBAs.
Understand the Supportability Parameters
The supportability of the storage support comes from the storage vendor. This also extends to iSCSI boot SAN scenarios per the KB article: https://support.microsoft.com/en-us/kb/305547/en-us. Even though the article does not mention Windows Server 2012 (or R2) it is still in place. Normally, this would not be complicated but in the case of iSCSI networks, the device may likely be using a NIC to locate the storage (especially if they are actually using NAS – network attached storage – i.e. NetApp) and not a traditional storage adapter or HBA.
Slipstream your 3rd-party drivers if possible
The use of slipstreamed NIC/Storage drivers in the installation ISO will prevent any timing issues from swapping back and forth between driver media and OS media. The may be especially the case if you are controlling headless blade devices using KVM or some other solution. I have found that this resolves many of the issues outlined in this particular KB: https://support.microsoft.com/en-us/kb/2826787 – as well as the 0x80070057 error message when trying to format drives or create partitions during the operating system setup.
No Thin-Provisioning LUNs for the OS Boot Drive
LUNS on the NAS devices (i.e. NetApp Devices) need to be thick provisioned for the drive containing the OS instead of thin-provisioned. In addition LUNS for the host OS boot volume only should be 127GB or less. Remember this is only in the context of the LUN being used for host devices iSCSI boot volume.
Avoid using Default Gateways for iSCSI NICs
The NICs configured for the iSCSI SAN should avoid having a default gateway. This can cause issues such as slow throughput occurring during formatting of disks and the copying of files during installation. This has been an issue with the Windows iSCSI initiator in the past and has previous appeared in KB articles:
960104: If you start a system from iSCSI, the gateway specified in the iSCSI Boot solution will always be used by Windows to communicate with the iSCSI Target
https://support.microsoft.com/kb/960104/EN-US
2727330: Default gateway is set to 0.0.0.0 if you start a Windows Vista-based, Windows 7-based, Windows Server 2008-based or Windows Server 2008 R2-based computer from an iSCSI boot device
https://support.microsoft.com/kb/2727330/EN-US
In addition, the network ports connecting to the boot volume iSCSI interfaces on the iSCSI network’s switch should have ICMP redirect disabled.
If all else fails . . . revert to the old way!
If the interactive installation still fails, remember – there is the legacy way of deploying Windows Servers in an iSCSI SAN boot configuration outlined in:
https://technet.microsoft.com/en-us/library/ee619722%28v=ws.10%29.aspx