VMware 4.0, EVA and cloning datastores

[Sheldon Smith]

Hi. Looking at a VMware vSphere 4.0 server. Been using MSA storage, just added an EVA 6400. We can create and present datastore storage just fine.

Now we find we want to take an existing datastore (EVA vdisk) and move it to a different vdisk (in a different disk group) presumably using the EVA to make a clone. Once it's cloned, how do we unmount the old datastore and mount the new datastore without creating a new partition, clobbering the clone?

Or do we not use the EVA to clone the datastore?

[Uwe Zessin · Accepted solution]

When you create a clone, you most likely will have to resignature it and re-register all VMs on that datastore. That is not such a great thing, beleive me.

Why not just create the new datastore and then migrate the VMs? If the licenses allow it, use an online "Storage VMotion" - if not, use vCenter's "cold migration" feature which will copy the data while the VM is powered off.

[Sheldon Smith]

Thank you, Uwe. It just seemed logical to offload the VMware servers and let the EVA do what it's good at. This particular datastore just contains install kits and images, so virtual machine motion didn't seem to be an issue.

[Uwe Zessin]

Yes, that makes coping a bit painful and a new datastore name could screw up some scripts.

There are some problems one could face:

- if you just unpresent the original and then rescan so that ESX removes the old SCSI LUNS is could have negative effects on *all* VMS, even if they are located on other datastores.

You can find some more information if you search for "all paths down" or "APD", e.g.:
c01908147 - VMware ESX Server 4.x - Server reboots when LUNs are presented/unpresented from EVA

- the original datastore is registered in the vCenter database and often linked by other objects, e.g. VMs, which makes deletion a bit hard.

It should be possible to remove the links, e.g. by unregistering the VMs, then deleting (!!) the original datastore, unpresenting the vdisk and rescanning. Then present the clone, rescan, resignature, ...

- Or, just unpresent the original and rescan (watch about APD). Alter the clone's LUN WWN to that of the original and present it under the original LUN address, then rescan.

- One way to minimize disruptions due to APD I've attemped once was:
-- migrate all VMs off one server
-- unpresent the vdisk from that server only
-- rescan
-- repeat with next server
I didn't encounter a problem, but, hey, maybe I was just lucky.


No amount of planning will ever replace dumb luck
(no, sorry, I did not invent that)