The primary aim of this post is to state categorically that VMware supports multiple storage arrays presenting targets and LUNs to a single ESXi host. This statement also includes arrays from multiple vendors. We run with this configuration all the time in our labs, and I know very many of our customers who also have multiple arrays presenting devices to their ESX/ESXi hosts. The issue is that we do not appear to call this out in any of our documentation, although many of our guides and KB articles allude to it.
Some caution must be shown however.
- If you have an SATP (Storage Array Type Plugin) that is used by multiple arrays on the same ESXi host, great care must be taken if you decide to change the default PSP (pathing selection policy) for that SATP) as the change will apply to all arrays – kb.vmware.com/kb/1017760
- Some storage arrays make recommendations on queue depth and other settings. Note that these are typically global settings, so making a change for one array will impact the queue depth to any other arrays presenting LUNs to that ESXi host – kb.vmware.com/kb/1267
- Another recommendation I would make, and I believe this is in our training materials, is to use single-initiator-single-target zoning when zoning ESXi hosts to FC arrays. This avoids any ‘fabric’ related events occurring on one array from impacting any other array.
With these considerations taken into account, having multiple storage arrays attached to the same ESXi host or hosts is completely supported. I’m going to see if I can get something into our official documentation about this.
Get notification of these blogs postings and more VMware Storage information by following me on Twitter: @VMwareStorage
Hi Cormac,
Nice to see the support in black and white
Given this support is there a way to turn off VAAI on a per array basis on an ESXi host? Saw this KB http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1033665 but that looks like all or nothing for a particular host.
Is it case of save claim rules, then delete relevant device claim rules or left to the Vendor or maybe there will be a new advanced variable in a future update?
Thanks,
Victor
Good question Victor – no advanced option to do this on a per array basis yet afaik.
While I haven’t tried it myself, it should theoretically be possible by not having the VAAI_Filter plugin claim the devices from the array and allow the devices to be managed directly by the PSA. You can list the VAAI_Filter rules using the following command to see what I mean – esxcli storage core claimrule list -c=Filter
I’m actually working on some VAAI collateral right now with a view to publishing something next quarter. Leave this with me and I will see if I can turn it off on a per array basis.
OK great thanks. I know Duco Jaspers and Chad were consulting on this because on CX4 HCL support on vSphere 5 so it may prove useful.
Look forward to more reading next quarter on the topic.
Hi,
I wanted to share one issue we are running into while testing storage failure. We have multiple XiVs connected to our vSphere cluster. When an ESXi-host goes into APD mode due to storage failure, even VMs with storage on other arrays are affected. So we are thinking about splitting our infrastructure, even with negative impact regarding vMotion/storage vMotion.
Regards,
Arnd
Would this functionality be supported with 2 HBA’s pointing to one Array\Switch and a second set of HBA’s pointing to a different Array\Switch?
Absolutely. That is not a problem and is fully supported.