Ever since we started our vSphere4 upgrade, our 6140 arrays are behaving well, but differently. Each new vSphere4 server we bring online results in an AVT (automated volume transfer) of a random lun. This process ,is ordinarily used for link failures or maintenance when the array needs to serve a host via an alternate path, which is of course the beauty of multiple-path I/O. Recovery Guru throws out a message like this:
As soon as we bring a new vSphere4 server onto the bus, it ‘walks’ the bus, and this results in a random lun or more moving between controllers. The first time it did this I was very dubious and went ploughing through logs before reaching a conclusion. However it’s repeatable and in reality fairly harmless, but if you see it, don’t panic, just move it back again and make sure your luns are balanced.
Why is it doing it? Well vSphere4 does a discovery on any bus, so it knows about all disks etc being offered or present on any bus. This is meant to be helpful in that you don’t have to use the virtual centre to do storage adaptor refreshes, it’s done for you. vSphere4 also tries to encapsulate any volume or lun it finds – all meant to happen, but on the sun/oracle hardware, just be aware of this side effect.
This is also the reason why with vSphere4 and crystal firmware, you MUST delete loon ID 31 to avoid any issues going forward with vmware having encapsulated your inbound santricity lun (lun 31)