ESX
cancel
Showing results for 
Search instead for 
Did you mean: 

VMware 4.0, EVA and cloning datastores

SOLVED
Go to solution
Sheldon Smith
Honored Contributor

VMware 4.0, EVA and cloning datastores

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?

Note: While I work for Hewlett Packard Enterprise, all of my comments (whether noted or not), are my own and are not any official representation of the company.
----------
If my post was useful, click on my KUDOS! thumb below!
3 REPLIES
Uwe Zessin
Honored Contributor
Solution

Re: VMware 4.0, EVA and cloning datastores

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
Honored Contributor

Re: VMware 4.0, EVA and cloning datastores

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.

Note: While I work for Hewlett Packard Enterprise, all of my comments (whether noted or not), are my own and are not any official representation of the company.
----------
If my post was useful, click on my KUDOS! thumb below!
Uwe Zessin
Honored Contributor

Re: VMware 4.0, EVA and cloning datastores

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)
.