I'm setting up iSCSI boot for UCS 2.0 and have a query about the 'Set iSCSI Boot Parameters'
When using a service profile template you only seem to be able to enter one initiator name in
the template and that same name is used for all service profiles created from the template. I
would have thought that this needed to be a pooled value? Am I right in thinking you therefore
can't use a service profile template when using iSCSI boot as it will result in all the
initiators being given the same name? Or have I misunderstood how that works?
Also, is there a naming standard we should use for naming initiators, should this follow iqn
conventions or just call it anything?
We'll be posting guides for many of the new features in 2.0. iSCSI boot configuration is one of them. These are similar to the guides we posted for 1.4 new features. This guide should help answer many of your questions. Give me a few days.
I have a question to about that, if it's a pool when you attach the new profil you can configure with the initiator the good ACL but if you delete this profil and put a new on other blade you boot the old system to the new blade no ? if you use the old initiator of a pool ? (yeah i know my english is poor sorry...)
no sure to about the pool... we will see in a few days...
Thank you for that, very useful stuff as I'm knee-deep in an installation right now!
Couple of follow up questions if you don't mind, as I'm having problems. Big ones...
Using the Palo adapter booting against NetApp, but during the boot process I get 'Initialize error 1' from the VIC iSCSI diagnostic screen. Any idea at all what that might mean?
Also page 131 of your doc says making the iSCSI VLAN the default VLAN is optional but UCSM gives a warning when you try to configure it using any VLAN other than native. So I can't really work out if the iSCSI VLAN has to be native VLAN on the switches or not?
The initialize error 1 means that for whatever reason the VIC could not see the UCSM configured iSCSI target. I know that's not very helpful as it can be any error in the configuration, UCSM boot policy, IP address, IQN, the list goes on.
When I first started this, the first thing I did was install W2K8r2 on local disk and then confirm all of my iSCSI configuration that I was going to use. So, I had the IQN, IP, lun masked and used that and made sure my local W2K8r2 install was able to mount that iSCSI volume. At least that eliminated all of the potential errors on the IP/iSCSI side.
Then, I just had to go through and make sure I had no UCSM SP config errors. No easy task. Sometimes I found it easier to start over than try and find some minor typo. As you do several of these successfully, you'll begin to see what errors you've made earlier. I made plenty of minor errors resulting in the initialize error 1 display.
I only tested the iSCSI IP target being configured in the native (non-tagged) vlan. I am not certain it you can tag the iSCSI target. If possible, try and test with the iSCSI target configured in the native vlan. It's not the native VLAN of the switch, it which VLAN you want to use without a tag (label). For instance, if you have vlan 45 set as your default/native vlan for your vNIC, your OS would see the network without the vlan 45 tag.
Once you have iSCSI boot working and are very comfortable with all of it's idiosyncrasies, move on to more complex networking
Following on from Dave, I quickly ran some tests in my lab setup (B200 / Palo / NetApp).
Whenever I had the iSCSI vNIC attempt to use anything but the native, UCSM would throw an error and the service-profile would have config-failure. The blade would attempt to boot, although I would eventually receive the error 'Initialize error 1'. The only way I was able to successfully iSCSI boot was when the iSCSI vNIC was configured on the native vlan.
Hope that helps.
Thanks both for the tips. I eventually did get it working. My problem was the iSCSI authentication profile. I had assumed, perhaps wrongly, that this was for CHAP authentication against the NetApp so had configured CHAP. As soon as I got rid of all the authentication it started working.
Thanks for the help.
Congratulations on getting iSCSI boot working. For those of you that have never performed iSCSI boot, it is definitely on the complexity scale of FC SAN boot, if not harder (my background is fc). It took me several, extremely frustrating weeks developing the powerpoint slides.
UCSM makes use of iBFT for passing the iSCSI boot configuration between all of the players (UCSM -> Adapter -> OS install). From what I've been reading, iBFT does not support CHAP during the OS install process, but, I could be mistaken.
The authentication we have in UCSM during install as described in http://www.cisco.com/en/US/docs/unified_computing/ucs/sw/cli/config/guide/2.0/UCSM_CLI_Configuration_Guide_2_0_chapter28.html#concept_D7BF302366F24CF5A602B0E0BD18787C
is not CHAP. It's more of a UCSM internal authentication scheme. I'll need to provide some additional slides and revise the doc to discuss this.
If you have any suggestions to improve the doc, please pass them on.
I was wondering how this is going for you. We were trying to get iSCSI to boot for ESXi and followed the Doc that you wrote Dave. We are running UCS 2.0.1m with B230 M2s and a NetApp filer. Looking through your guide it looks supported - looking through the interop guide
http://www.cisco.com/en/US/docs/unified_computing/ucs/interoperability/matrix/r_hcl_B_rel2_0.pdf (pg 4) its not supported. Is there interop doc getting updated? or is it a very limited set of hardware that this will work on?
Been banking our heads against a brick wall for days.
I just checked and the interop guide does have errors and is being updated. I have tested B200M1, Palo/BRCM, NetApp and ESXi 4.1U1 successfully. I don't have a B230M2 to test with, but, I'm very sure it will work. Once the interop matrix is updated, it should reflect the B230M2.
Where is your install failing?
1) Do you see the CiscoVIC/BRCM initialize successfully? If not this is a UCSM/NetApp config error, somewhere. At this point the OS is not in the picture. It's pure UCSM/NetApp.
2) DId the mezz initialize successfully, but the OS cannot find a install disk? Make sure you have a released version of ESXi (eye) 4.1U1. ESX classic (non-i) does not support iBFT.
We were using ESXi 5.0 - but tested 4.1U1 also.
We see the disk for install (ESXi5.0 & 4.1U1)... so the assumptions is that iSCSI is working correctly. 5.0 stopped 90% through, 4.1 installed then gave a crazy error on reboot.
ESXi 5.0 was the real driver for this so we are going to regular FC config. We are going to tear down the config we had - but if you want me to grab anything before we do - let me know. Looking forward to 5.0 being supported on iSCSI.
5.0 support didn't make it for 2.0(1m). No sense banging your head on that one. Only ESXI 4.1 U 1 is currently supported.
One thing to check, no local disk installed, right? The issue with local disk, is even though we can specify SAN (fc/iSCSI) install and boot, the OS can in certain instances lay the boot tracks onto the local disk. So, we currently only support SAN (fc/iSCSI) boot with no local disk installed.
Any chance you can grab the reboot error screen shot? Also, can you grab the CiscoVIC initialization success screen shot.
You got me stumped for now. I don't recall running into that failure when I was doing all of my testing. It looks like it sees boot tracks, but, can't find the OS on the same disk.
On your NetApp, if you run: igroup show, do you see your iSCSI initiator logged in?
Something like this:
Data ONTAP (cae-sj-netapp2.)
cae-sj-netapp2> igroup show
iscsi-palo (iSCSI) (ostype: linux):
eui.87654321deadbeef (not logged in)
iscsi-brdcm (iSCSI) (ostype: linux):
eui.12345678deadbeef (logged in on: e0a)
esxi4u1-palo-igroup (iSCSI) (ostype: vmware):
iqn.2011-09.com.cisco:esxi4u1palo (not logged in)
Not too worry... we are moving forward with the FC mode.
We did run igroup show and the initiator was logged on.
Simon thanks for the images.... In looking over your screen shots I know that we didn't have Native VLAN checked.
Maybe that was our issue
We will wait for 5.0 to be supported and then try again.
Thanks for the quick responses.
I get the Cisco UCS "Cisco VIC iSCSI, Boot Driver Version 2” + “Initialize error 1" when using 2 iSCSI vNIC's laid over 2 vNICs with Palo M81 cards. If I use 1 iSCSI vNIC laid over a vNIC it works just fine. I am on 2.0(w). Thinking what happens is both cards are trying to login and that screws things up. First works as you see below. I hear from my NetApp friends they have trouble with this also.
Can only one Initiator login to a Target? Will a second logging in kick both Initiators out?
It does appear to work at first
Than get the tragic “Initialize error 1” error! But I do see a initiator logged into Isilon for a while. Then it fails.
With only on iSCSI Initiator all works fine. It is the second that hoses it.
My Boot Profile
Each iSCSI vNIC has the same Initiator ID, and is logging into a different IP on the Isilon x400 (one for each FI, have "no failover" set. Thinking "SAN Like" in my setup. Guess could try different Initiators, one for each iSCSI vNIC and allow each on Target??? Not sure if that is common practice.
Try giving each iSCSI Initiator a unique IQN name. Duplicate IQNs will cause a major issue if/when upgrading to the 2.0(2) Maintenance Release coming out in a week (or two).
You'll obivously need to mask the additional IQN to your boot LUN on the array also.
Let us know if that works.
Thanks for the reply!
Created a unique IQN name for each Initiator, and updated the Target authentication to match Isilon side.
Still getting the "Cisco VIC iSCSI, Boot Driver Version 2” + “Initialize error 1" error.
But the iSCSI Target does no go offline after bootup. So at least on an Isilon multiple Initiators must have unique names.
Looking on my Isilon NAS only one path is active but that is to be expected until after bootup.
Trying to image now (looking good), will reply later with a thumbs up or down if this setup gets along with Winodws 2008R2.
If you're still having issues, try this. Once the host has booted and you see the initialize 1 error message, issue the following commands from the UCSM CLI:
connect adapter x/y/z (chassis/blade/adapter#)
Post this output.
Found you can get around this error by creating 1 iSCSI vNIC in Boot Profile. Add two Targets (to same LUN) using the Target IP attached to each FI. Just be sure to enable failover on overlaid vNIC. This is still one Initiator ID but think that is OK.
We are blue screening on startup as the servers boots, but it almost makes it. Think it is a driver issue. Funny the servers image with SCCM no problem, then don't boot.