I would appreicate some advice on the below situation I find myself in, and some inout from peoples experiences.
I am moving VMs to a shared data store which is presented to a 4.1 and 5.5 cluster.
So far I have been happily moving VMs and removing them from one vCentre another to eventually decom the existing 4.1 environment.
I am now moving servers housing Exchange mailboxes. These contain approx 7 RDMs of about 700GB in size.
Shutting down the VM and performing a SVMotion presents a error stating there is not enough storage on the destination data store. Now I am guessing it is attempting to convert the RDM pointers into VMDKs as when the VM is powered on and I attempt the SVMotion I do not get the error and I can progress further through the wizard.
I have not completed the wizard as I am concerned that I may face further issues I have not come across. Can I expect the same behaviour as previous VMs where by I SVMotion, the RDMs while the VM is on, shut down, remove/add to inventory from old vCentre to new (4.1/5.5), power up and carry on as normal (after upgrading the hardware etc etc. Is there anything I should be aware of, I should the servers just be rebuilt in the new environment?
Thanks for any advice in advance.
Exchange deserves its own level of caution..... are you also changing storage frames in the process?
Because of the performance issues with exchange, DAGs and high perf SQL on frames, we found that investing in Storage Foundations gave us a lot of flexibility.
Thinking out loud here, you probably want to keep the pRDMs for performance reasons however the local system partitions hopefully are vmdks and the data volumes are pRDMs,
I'd want to have a back-out plan in case your vhardware\tools upgrades go bad consider this.
add 7 pRDMs in vmfs to your existing dags, create mirror for your drives...hopefully the partitions are already dynamic and let them replicate and build the mirrors. Hell you could even mirror to vmdks.
On go night set all your svcs to manual using msconfig, then shut down the server (Make sure you document the complete configuration of your server, pointers and devices)
Clone your existing server or copy the VMDKs to the new storage. Move the pRDM copy LUNs to the target New VMs Configuration, choose "you copied the files" on boot and rename the vm then straighten out your Volumes (import Disk etc.) insuring correct paths.
Once all is up then upgrade your tools then hardware.
Test (Beware of mac issues) and if all goes well you're done...if it doesn't, shut it down then power up the original box and plan accordingly.
Put it in a lab and test out, read up on MS Software Mirroring
Hope this helps..good luck
DGN, thank you for your detailed response.
There are some points I am a little unsure on so please bear with me. I attempted to clone the VM but I was not allowed to do this because of the RDMs (not sure if this is a 4.1 limitation) otherwise I would love the ability to do that, test and have a roll back plan.
So far all the hardware upgrades and Tools installs have been fine but you know what with sodz law and all that so ideally having a backup/blackout plan is a must (in a ideal world). the SAN in question is NetApp so potential I could take some sort of snapshot on the SAN side which may help. I have the NAAs, and IPs for the server documented.
I got a bit lost when you were talking about mirrors/vmdks etc (can you explain this another way I'm open to any suggestions which might provide a roll back / get out of jail plan). the system drive is VMDK, the rest are RDMs, I don't want to convert them to VMDK, I'm not comfortable in doing that. This company has no budget (or time) for 3rd party software so I am on my own here.