Vaai Unmap

Chad muses on being more open here on providing information to partners and customers and then inadvertently proves it by succinctly identifying that Unmap for VAAI returns in update 1 but is no longer automatic, but instead a vmkfstools command.
Probably the only way to easily reclaim space on thin provisioned volumes right now without the long delays or timeouts.
No doubt VMware’s engineering effort will continue and we’ll see it added back as an automatic process in a later update.

Advertisement

EMC ProSphere

If you’re managing any reasonable sized VMWARE farm and using EMC storage then this is for you.

http://virtualgeek.typepad.com/virtual_geek/2012/03/emc-prosphere-15-play-learn-try.html

The biggest management headache we face as virtualisation admins is identifying storage performance issues in what can be a complicated environment. I’ve always lamented the lack of a tool that can discover and link all the components together and get one view. Finally EMC have delivered by the looks of it, I haven’t yet tried it out yet, but once I have I’ll post my thoughts.

Hint, hint EMC, maybe develop this further to work with other vendor’s arrays?

SanSymphony backend active/passive array support

An interesting issue popped up recently when we started to allocate LUN’s from our existing EMX CX-320 arrays to our Sansymphony SAN virtualisation servers.

At it’s simplist, it has to do with any storage array that implements active/passive controllers and trying to connect them to SanSymphony as backend storage.

I’ve got another post in the pipeline which details how we’ve used Sansymphony in our environment but I felt this is an interesting issue to highlight for those either using or going to use SanSymphony to virtualise mid range storage array’s like the Clariions that use active/passive designs.

For those people who haven’t had a lot of exposure to Sansymphony, you need to be aware that SanSymphony utilises it’s own FC HBA driver to implement various features that otherwise aren’t available in a normal Windows server HBA driver; like acting as a target. So because SanSymphony uses its own driver out of the box, other MPIO utilities like Powerpath aren’t able to be used on these storage servers. (Well not totally true but that comes later)

It also means that SanSymphony will actively try and use all paths to a backend target for active IO.In most cases active/passive arrays will signal that a passive path is up but when an IO request is sent down the path, the array will signal back with “Not Ready”. SanSymphony then appears to retry the command down the same path over and over. This leads to a situation where when you first try and add a new back-end LUN to SanSymphony you’re quite likely to discover that it can’t be deiscovered. Even worse is if for some reason you do manage to add it to a disk pool it could end up unavailable should the LUN be transitioned to the alternate storage processor.

According to the Datacore Tech bulletin 1302, the recommendation is to set aside HBA controllers to connect to these SAN arrays and use the array’s supported software/drivers instead of SanSymphony’s drivers on the back end port. By doing this you won’t be able to use those ports for any other SanSymphony function (such as front end or mirror ports). The only alternative is to only zone in and register paths to only one of the back end array’s storage controllers and set the host and LUN to auto trespass to that controller. I’d caution that this is really only a stop gap measure while you migrate volumes off of the array and not a permanent solution.

As always with SanSymphony it’s best to plan your connection options carefully at the start, messing around with drivers with a storage controller in production is asking for trouble if it’s done wrong.