Archive for the ‘Storage’ Category
NetApp unified SRA requires NAS and SAN RBAC
Rawlinson Rivera blogged about a known issue with the 1.4.3 version of the NetApp SRA a while back. If you’re not familiar, this version marries the seperate NAS and SAN versions that previously existed. If you read through the comments you’ll discover that the documented issue occurs in NFS only environments where no iSCSI or FCP LUNs exist. As explained in the NetApp knowledgebase article (NOW access required), the workaround is to create a dummy VMware igroup:
igroup create -i -t vmware sra_dummy_igroup
After recently implementing the workaround, we continued to receive a LUN discovery error until we finally remembered that the filer permissions required for the older NAS and SAN SRAs were different. During our original setup, we had configured role based access control with the requirements for NAS only. Unfortunately, to complete a successful discovery with the new unified SRA, it appears that RBAC must now include the permissions for both NAS and SAN, even if you’re not using one or the other. Luckily for us, a quick look back at the NetApp SRA RBAC rights knowledgebase article (NOW access required) got us back on track.
Cisco UCS C-Series, VMware & RAID
A colleague of mine reminded me of a hardware configuration consideration regarding Cisco UCS C-Series servers today so I thought I’d share. As specifically noted in the Cisco UCS C-Series Servers VMware Installation Guide, VMware does not support the use of the onboard Intel ICH10R based software RAID controller. This isn’t anything new, as VMware has never supported software RAID. Just make sure you add an LSI 1064-based controller mezzanine card to C200 and C210 servers or an LSI 3081-based controller to UCS C250 servers when you order.
update to Nexus 1000v, IP-based storage & jumbo frames
There’s been an issue for a while for 1000v users running jumbo frames on storage networks. The problem is that the 1000v VEMs do not retain MTU settings and boot with a default of 1500. Until the VSM is up and communicates with the VEM to change the MTU, IP-based storage is not available. If my VSM is on this storage, then this creates the “chicken and egg” scenario. For further details, check out Trey Layton’s explanation. NetApp offers an interesting workaround, and I’ve been having customers put one VSM in an HA pair on local storage to avoid the scenario. Cisco had told us that there was a fix coming, and apparently it has arrived. I recently installed 1000v version SV1(3) for a customer and noticed there’s now a command called “system mtu” that can be applied to ethernet port profiles. Just like you specify “system” vlans that can come up without the presence of the VSM, it appears that “system mtu” allows you to set the MTU of those VLANs as well. Finally, no more workarounds.
Configuring the NetApp SRA to use SSL
Cormac Hogan produced a great Proven Practice document a while back detailing the steps needed for configuring the NetApp SRA to use SSL communication instead of unencrypted http. The steps involve using PPM to download the Perl libraries needed for SSL communication. If the 27 page document seems a little daunting, and RTFM is not for you, then how about the two steps below:
1. Download the libraries here and drop them into C:\Program Files\VMware\VMware vCenter Site Recovery Manager\external\perl-5.8.8
2. Modify the ontap_config.txt file found in C:\Program Files\VMware\VMware vCenter Site Recovery Manager\scripts\SAN\ONTAP_NAS and set the SSL option to on.
Now, obviously this assumes you’ve already enabled SSL Secure Admin on your filer, etc. If not, take a look at Cormac’s guide. Either way, hopefully the libraries above will save you some time. 
SRM 4 and disappearing iSCSI LUNs
It appears that Site Recovery Manager 4 ships with a default advanced option that is potentially very dangerous for iSCSI users who run production VMs at the recovery site. The option is “SanProvider.removeStaticIscsiTargets” and it is enabled by default. It isn’t quite clear exactly why it comes enabled, but the result is that during the cleanup of a recovery test, all iSCSI targets are removed. This includes any targets that are potentially running production virtual machines! A couple of colleagues stumbled across this issue during a multi-site deployment last week. In this case, SRM removed an iSCSI target with LUNs containing not only production machines, but the DR vCenter and SRM machines too! Hopefully this will be corrected in a future update, but for now, go disable this option!
vSphere, MSCS, and slow boots
I recently released VMware KB hit the nail on the head for an issue I came across recently. It involves the number of SCSI conflict retries the vmkernel will attempt before passing on a LUN. This is an issue for ESX hosts with a large number of MSCS guests. Since the active MSCS node is reserving the RDM LUNs, VMware cannot gain access. The fix changes the number of retries from 1000 to a mere 80. I’ve actually seen others recommend just 10 too. In my case, because this particular environment had so many MSCS clusters (over 150 MSCS RDMs), we took the additional measure of creating dedicated VMware clusters to host the MSCS VMs and unmasked the RDMs from the other ESX hosts.