Anyone tried this yet? I know a lot of VMWare people are probably doing this. I have Xenserver running when installed on the local storage (does not require iscsi vnics) however I can not get the iscsi boot working.
After reading all the documentation I can find on the subject, at the Xenserver install screen you are supposed to enter multipath mode but that's not actually a real option here since I'm not doing multipath to the backend storage for my dev Xen environment.
At any rate, when I'm booting up the blade I do see an iscsi initiator connection on our NetApp so I think the iscsi vnic is working correctly (my boot policy is set as CD-ROM then ISCSI boot).
So at this point, I'm not sure if it's a problem witt my iscsi vnic setup on the UCS or if it's a problem with XenServer itself. If I go through the normal install steps on Xenserver it will load ot the local disks, even though my local disk configuration is set as "No Disk Policy".
Can anyone please send me in the right direction? I figure if I can just get Xen loaded then it will boot correctly since I see the iscsi connection to the backend storage - I just can't tell what the problem is at this point.
Incidentally, I see the following message on the NetApp right before seeing the subsequent "Initialize error 1" message on the blade - SO, it appears the iscsi connection is being made to the NetApp, however, I still see the error on the blade.
OxNas1-F2> Mon Jun 4 10:12:34 EST [OxNas1-F2: iscsi.notice:notice]: ISCSI: New session from initiator iqn.2012-06.com.example:xenucs02 at IP addr
One other thing : running the following commands from the FI shows the output below. Not sure why the "State" of the target is "INVALID"
----------------------------------------------------------------
connect adapter x/y/z (chassis/blade/adapter#)
connect
attach-mcp
iscsi_get_config
-----------------------------------------------------------------
vnic_id: 8
link_state: Up
Initiator Cfg:
initiator_state: ISCSI_INITIATOR_READY
initiator_error_code: ISCSI_BOOT_NIC_NO_ERROR
vlan: 0
dhcp status: false
IQN: iqn.2012-06.com.example:XENUCS02
IP Addr: 2.2.2.239
Subnet Mask: 255.255.255.0
Gateway: 2.2.2.1
Target Cfg:
Target Idx: 0
State: INVALID
Prev State: ISCSI_TARGET_GET_LUN_INFO
Target Error: ISCSI_TARGET_GET_HBT_ERROR
IQN: iqn.1992-08.com.netapp:sn.135113177
IP Addr: 2.2.2.101
Port: 3260
Boot Lun: 0
Ping Stats: Success (10.090ms)
I've already tried the following docs :
http://docs.vmd.citrix.com/XenServer/5.6.0fp1/1.0/en_gb/installation.html#boot_from_san
http://www.cisco.com/en/US/prod/collateral/ps10265/ps10276/whitepaper_c11-702584.html
Doing Multipath iscsi boot is a whole other animal at this point - I'll tackle that one next
Thanks everyone
Thanks for the reply Ganesh.
We have B200M2 blades with the M81KR adapter. I see the iscsi connection being made successfully so I know that is working (see attached screen shots).
1) I can see the iscsi LUN being connected to the blade via the Cisco VIC (iscsi vNIC)
2) I can see the iscsi LUN connection at the adapter via the FI
3) I can see the iscsi LUN connection at the NetApp backend storage
4) I'm choosing the recommended option at the Citrix Xenserver installer splash screen which is supposed to allow the presentation of a remote LUN to the installer
-----
-----
-----
So here is where I am stuck. As far as UCS is concerned, I think I have the iscsi LUN connected successfully - the trick, how do I get Xenserver (or any VMWare, or any other hypervisor for that matter) to recognize the remote iscsi LUN when installing??
One other side note, if I go the "shell" mode via the Xenserver installer, none of the ethernet NICs have any configuration, so something is definitely missing. In my case, the iscsi vNIC on the UCS is NIC #3 (eth3), but as you can see when looking at the linux config (via the Xen installer), the nic has no config so I'm not sure how Xen would ever see that iscsi connection to the backend storage - SO, does a UCS linux driver need to be installed for Xen to see the iscsi vNIC being offered up by UCS? Argh - I don't know.
UPDATE
At any rate, I've made a little more progress based on this article
If you go into "Shell" mode on the installer and issue "/opt/xensource/installer/init --use_ibft --mpath", the installer will be loaded using the multipath method with access to the remote LUN (I imagine this is the way the "multipath" option is supposed to work). I know this part is working correctly because Xen correctly recognizes the NIC I am using for iscsi boot (see pic 1). Unfortunately, I get an error message saying it can't access the LUN, even though it knows the correct NIC to use.
Stuck again .. anyone seen this message? What a pain .. I thought iscsi boot would be easier ..
UPDATE
I now see that once you specify the iscsi IBFT mode for the Xen installer (see the pics in my above post) that Xen is trying to connect to the backend LUN with a randomly generated open-scsi IQN - I was under the impression it would use the previously created IQN from the iscsi NIC (in this case, provided by UCS - Cisco VIC).
Red is for the UCS VIC IQN, Green is for the randomly generated Xen IQN.
Now I see two independent iscsi initiators on the NetApp, one for the UCS VIC and one for Xen itself - the trouble is that since the Xen IQN is randomly generated each time, I can't give permission to the LUN on the backend. I assumed Xen would use the previously generated iscsi connected (since the Xen installer actually ASKS WHICH ENTRY TO USE FROM THE IBFT) .. but no .. it's trying to connect to the backend LUN instead of using the already established connection.
I'm looking through the xensource installer files now to see if there is a way to hardcode the IQN to be the same as the IQN on the iscsi vnic provided by UCS. Once the installer fails, it puts you back out the linux (bash) prompt and you can see that an initiatorname.iscsi file was created with the random IQN. Million dollar question - how do you get Xen to use the previously created iscsi vnic and it's associated IQN instead
UPDATE
I followed this article (http://www.rienbroekstra.nl/?q=node/19) and was able to map to the iscsi LUN manually. Here are the initial steps, as outlined in the article :
1) Insert relevant kernel modules
modprobe scsi_transport_iscsi
modprobe iscsi_tcp
2) Configure our initiator name, replace the name with whatever is correct for your organisati
on
echo "InitiatorName=iqn.2010-01.com.example:whatever" > /etc/iscsi/initiatorname.iscsi
3) Start the iscsi daemon
iscsid
4) Configure the network interface which is to be used to access the iscsi target, and bring it up
ip addr add 1.2.3.4/24 dev eth0
ifconfig eth0 up
5) Discover the available targets on your iscsi filer (This step is necessary,
even if you know what the correct target is)
iscsiadm -m discovery -t sendtargets -p 1.2.3.1
6) Connect to the target
iscsiadm -m node --targetname iqn.2006-01.com.openfiler:whatever -p 1.2.3.1 --login
7) Kill and restart iscsid. I'm not sure that this is necessary, but it might write the correct configuration to /etc/iscsi/, so I guess it can't hurt.
8) Exit the shell in order to start the installer.
exit
Once you do these steps, Xen will recognize the iscsi LUN and be able to install to that LUN (see attached pics).
The problem now (of course) is that once it boots up again, it hangs on the "Citrix XenServer" splash screen indefinitely. The article above says this is due to an error in the initd in Xenserver - its assuming you are using DHCP, so it does not get the correct IP settings for the iscsi NIC when it is rebooted. There are a set of secondary steps in the article above as well to rectify that but I can not get those to work - I cannot mount the sda1 drive as is indicated in the article.
Here is the thing though - we should not have to do any of these manual steps. I am presenting an iscsi NIC (from UCS) to Xenserver via iBFT. Xenserver in turn is supposed to be taking those NIC settings (ie. IP addr, IQN, etc) and connecting to the backend LUN automatically.
I'll try this other suggestion of running the "mkinitrd"command to hopefully update the installer after manually creating the initiatorname.iscsi file with the correct IQN - this may not work either because the IP address on the dedicated iscsi NIC may not get set.
Frustrated ..
