Thursday, May 26, 2011

XenServer iSCSI multipathing

Like many others, I use XenServer with a iSCSI SAN. To leverage a single point of failure, I enabled multipathing. When the IP or path of a host adapter changes, it can be challenging to get XenServer to recognize the new path.
The kb articles that Citrix provides about such issues are good pointers, but some commands are just plain wrong.
So this should serve as my little cheat sheet, and it might help others out there as well.

Check existing iSCSI sessions:
iscsiadm -m session
More verbosive information can be gathered with:
iscsiadm --mode node --loginall=all

If an IP has indeed changed, the old path needs to be forgotten. This can be done with:
iscsiadm –m node –T iqn.2008-01.com.openfiler:store01.lun01 –-portal=ip-address-of-the-storage -u
To reactivate a SR with multipathing one needs to get the SCSI ID from XenCenter, and then issue this:
mpathutil.py add
This step didn't work for me, however. Here's what did work in my case. Discover the targets manually:
iscsiadm -m discovery -t sendtargets --portal=ip-address-of-the-storage
Then, with the iSCSI IQN manually log on to the target:
iscsiadm -m node -T iqn.2008-01.com.openfiler:store01.lun01 --portal=ip-address-of-the-storage -l
This should yield in something like this:
Logging in to [iface: default, target: iqn.2008-01.com.openfiler:store01.lun01, portal: ip-address-of-the-storage,3260]
Login to [iface: default, target:
iqn.2008-01.com.openfiler:store01.lun01, portal: ip-address-of-the-storage,3260]: successful
The added path should immediately be shown in iscsiadm -m session. If there are still issues, restart the multipath daemon:
 service multipathd restart
It's noteworthy that this doesn't disrupt any services. So it should be safe in a production environment.

If XenCenter still reports wrong number of active/inactive paths, a refresh can be forced by running:
/opt/xensource/sm/mpathcount.py
 

Monday, May 23, 2011

XenServer 5.6 and Dell OpenManage 6.5

Citrix recently released XenServer 5.6 Service Pack 2. While you probably have found out already, that upgrading from XenServer 5.6 FP1 only works through XenCenter and not by booting from the ISOs, those of you running XenServer on Dell boxes might appreciate some pointers in getting OMSA up and running again.

Dell actually recognizes XenServer as an operating system for their servers, so there is an ISO that can be used as supplemental pack when XenServer is installed. Yay! The same ISO can be used to install it on an existing system. Instructions can be found here, at Dell's Enterprise Technology Center. This site also has directions where the latest OMSA download can be found, so check it out!

I had OpenManagae 6.4 installed on all of my XenServers prior to upgrading them to 5.6 SP2. The installer failed because some conflicting packages were already installed. So I basically had to remove OMSA 6.4 before I could install 6.5. To save you the hassle of identifying the individual packages, here's how to get rid of it quickly:

yum remove srvadmin-smweb srvadmin-smcommon srvadmin-omilcore srvadmin-sm srvadmin-iws libsmbios sblim-sfcc
 After running the install.sh script on the downloaded ISO, it is necessary to bounce the srvadmin services by issuing:

/opt/dell/srvadmin/sbin/srvadmin-services stop
/opt/dell/srvadmin/sbin/srvadmin-services start

Thanks to jh for pointing out the mistake.