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:
It's noteworthy that this doesn't disrupt any services. So it should be safe in a production environment.service multipathd restart
If XenCenter still reports wrong number of active/inactive paths, a refresh can be forced by running:
/opt/xensource/sm/mpathcount.py
0 comments:
Post a Comment