Subscribe

Citrix XenServer 5.5 StorageLink integration w/ NetApp

Hi,

I'm installing a FAS2040A w/ ONTAP v7.3.2 into my first XenServer v5.5 environment and the customer has chosen to use the 'Citrix Essentials' StorageLink way to share storage (ie as opposed to basic iSCSI or FC LUNs manually created and assigned to each XenServer).

I've just been checking over his environment and it appears that StorageLink has created all of the LUNs in his environment with a multiprocol type of 'image' rather than 'linux'.

I think I remember reading somewhere that linux could use 'image' or 'linux' multiprotocol types in previous versions of ONTAP, but I just wanted to check that this is normal or if it's going to create any issues down the track (ie block alignment etc).

Does anyone else with XS 5.5 use StorageLink and see this behaviour?

Cheers,

John

zhu Former NetApp Employee

Re: Citrix XenServer 5.5 StorageLink integration w/ NetApp

If the customer does not choose any protocol, it will be default as image. We recommend customers to use proper OS type based on the VM OS.

Re: Citrix XenServer 5.5 StorageLink integration w/ NetApp

Yeah but the problem is that the LUNs are being created by XenServer StorageLink - NOT manually within ONTAP and then mapped to an igroup etc. There is no facility in StorageLink to specify what LUN multiprotocol type should be used (ie either 'xen' or 'linux' in this instance).

This core problem is more likely an issue with XenServer StorageLink itself rather than anything to do with ONTAP, but the question I need answered is will using LUNs with 'image' as the multiprotocol type cause any block alignment issues or will it be ok in this instance?

Many thanks,

John

zhu Former NetApp Employee

Re: Citrix XenServer 5.5 StorageLink integration w/ NetApp

http://media.netapp.com/documents/tr-3747.pdf

Check TR3747 section 5.1 to see if the system is misaligned. I will ask Citrix PM about the StorageLink issue.

Re: Citrix XenServer 5.5 StorageLink integration w/ NetApp

Hi,

has there been any update to this? Perhaps storagelink version 5.6 has rectified this?

Thanks,

Aaron