My reasoning is that someone that wants to use Boot from iSCSI is setting up something new since you're most likely not shifting an existing production system to Boot from iSCSI. So I would begin with the hardware that Dell would recommend to anyone looking to purchase a system with the intention of using Boot from iSCSI.

My guess is that the recommendation from Dell would be the enterprise 11G servers (R610/R710/M610/M710) which all have the Broadcom 5709 onboard with the optional ISOE (which would a nice feature to have if you're going to use Boot from iSCSI). You pretty much can't get a Dell server without Broadcom NICs so Intel, while an excellent NIC, must be the second choice when making a guide. Next up is storage and I'm fairly certain that Dell would recommend EqualLogic before EMC AX4/CX4 since this is a strictly iSCSI scenario and EqualLogic is the pinnacle of Dells iSCSI offerings. The third component would be the operating system. I think you should try to push the new versions of Windows, Red Hat and SLES out the door first. That means Windows 2008 R2 (hopefully implementation is identical with Windows 2008) and then RHEL 5.4 and SLES 11.

In the current guide Ghost is used in various steps to facility image cloning. I think many would prefer native solutions to this. The much improved image handling in Windows 2008 (R2) could probably be used instead of 3rd party utility like Symantec Ghost and native solutions most likely also exists in RHEL and SLES.

To summarize the most important configuration:
NIC - Broadcom with ISOE (5709, 5708, 57711, note sure wether 5716 in the lower end servers support ISOE)
Storage - EqualLogic
OS - Windows 2008 R2, RHEL 5.4, SLES 11

Jeff,

Has there been any other input on this matter?

Not as of yet, but the team putting the paper together did look at your input.

"We’d like your input! Our Storage Interoperability Lab Team is looking at updating this document:
“Instructions to Perform Boot from iSCSI for Dell Storage Arrays”
http://support.dell.com/support/edocs/network/BFi/

"

There's a problem with the document - it points to the community forum, then back to here. The actual document itself is nowhere on the support website, so it's going to be difficult for us to have a reference point for what you currently have written.

Can you get that document posted here, or back to its original location?

Rather then feedback on the old document (which was out of date), we would like to hear about your current needs & challenges re. setting up and managing a boot from iSCSI SAN environment. For instance, andreaserson's feedback was valuable. Do you agree with his recommendations?
Thanks!

ajhicks,

bing has it cached here
http://cc.bingj.com/cache.aspx?q=dell+bfi&d=4663982342147436&mkt=sv-SE&setlang=en-US&w=7ecdd24d,128ae5fe

google has it cached as well, not as pretty formatted as the bing cache though

Jeff,
This sounds all very good and I see some opportunities here.
What about vSphere ?
Will this also work and how do you do it?

FWIW, I agree with Andreaserson's hardware recs for new documentation, but would add that Vsphere may be a 1st run scenario to consider from an OS perspective. In our data center we are tending to deploy more virtualization layers than direct OS in boot from SAN/iSCSI deployments. Might prove useful doc for Dell customer base.

I would add best practices for various BIOS options, including TOE, iSOE, and I/OAT

From Bala C.- Dell lead engineer on VMware vSphere business ready configs (also balacs on VMTN)

“Only ESX hosts with hardware iSCSI initiators can boot from SAN.” http://www.vmware.com/pdf/vsphere4/r40_u1/vsp_40_u1_iscsi_san_cfg.pdf (page 51)

In short, iSCSI boot from SAN with vSphere requires a HW iSCSI initiator.

neomag00:
I totally agree. Just like vSphere, Windows with Hyper-V is a virtualization layer so they should both be high on the priority list.

khsieh:
Very good idea. We should also gather bios best practices and put them on delltechcenter (maybe there already are some?).

KongY:
Does the Broadcom 5708/5709/57711 with ISOE count as a HW iSCSI intiator in regards to iSCSI boot from SAN with vSphere? I'm guessing no.

Andreas,

http://www.delltechcenter.com/page/Enabling+iSCSI+Adapter+on+Broadcom+5708+on+R805

The 5708 with TOE and the licensing feature will enable it as a HW iSCSI initiator. Accordingly, if set up correctly, it should work with iSCSI boot from SAN w/ vSphere.

Nice, I'm going to include how to setup 5709 with ISOE (iSCSI Offload Engine) enabled when connecting to an EqualLogic with Windows 2008 R2 in my upcoming Hyper-V R2 guide eXtravaganza. :-)

Hey Guys,

Will be good to get some boot from iSCSI for EQL and Broadcom togeather. There isn't a lot at the moment.

Quick Question, have any of you guys had CHAP auth problems on EQL 4.1.4 with Broadcom iSCSI HBA NICs in our M605's? No matter what I seem to do it won't auth with any chap user. Switch to IQN auth works fine and can connect to the volume.

EDIT: It's ok guys, found I was using two-way chap auth instead of one-way.

HI all,

I am an analyst in Support, and have been dealing with quite a few boot from iSCSI escalations on both our MD3000i product, but mostly with BFi on our EqualLogic brand. I am working on some internal docs (complete with screenshots) on various implementations of BFi on the EqualLogic storage platform in conjunction with the various operating systems (ie, Windows Server 2008 R2, vSphere, etc.) using both a software initiator as well as the supported QLogic hardware HBAs.

One of the issues I have come across which I will share with you is during the installation of the OS portion or even the installation of software in general from external media sources, such as USB devices, as well as during the implementation of MPIO using the H.I.T. kit on EqualLogic arrays, is that after the initial install of the OS, software, or MPIO, a reboot is required, and during this reboot the system will do one of two things: it will either blue screen, or it will automatically reboot, at which point it gets caught up in a bootloop.

The resolution to this issue is to remove, or detach, any external USB devices (ie, key, hard drive, DVD/CD-ROM, etc.).

This is, of course, is only one of the many issues I have handled in Support of BFi implementations on both our MD3000i and EqualLogic storage platforms.

If anyone is needing some assistance with the creation of this documentation, or just wants to share some ideas, please feel free to contact me.