I’ve been busy migrating a VMware vCenter Lab Manager installation from an EMC AX150i SATA-II iSCSI SAN to a CX3-10c 10k FC disk SAN using SSMove. As I’ve experienced many times before, SSMove isn’t as robust as it should be. In this case, it refused to move a linked clone disk chain from a LUN on the AX150i to the CX3-10c. It kept telling me that some virtual machine folders were already present on the target LUN, no matter how often I deleted them from the target and started the move again. The exact error was

“Host “esx01” has reported an error. Requested file “/vmfs/volumes/4cea58db-75a2ccd2-8774-0019b9e37a1d/lm/978″ is already present.”

I went to the VMware Communities site, and stumbled upon a post by IamTHEEvilONE where he hinted at being able to do SSMove’s work manually:

(…) the data changed location (new UUID) so update the DB and VMDK headers. It’s just that we have tools to help recover from this, and is intended to be used when SSMove fails.

Since SSMove actually already moved the files to the destination, I wanted to try to edit the VMDK’s/VMX’s and DB myself.

So I started digging. First off, I gathered all the information on the source and target datastores, like name and UUID. I then examined one of the VM’s that wouldn’t move, determining which information inside the VMX and VMDK files linked it to the datastore or to a master. I found a couple:

Inside the VMDK Descriptor file, there was a link to the parent VMDK:


Inside the VMX, there was a link to the location of the vSWP file, on the source datastore:

sched.swap.derivedName = “/vmfs/volumes/4afaa422-db134e6c-818f-0019b9e37a1f/000865-SLES10-4-c3259984.vswp”

My skills for using SED, a great find and replace tool for Linux, are nowhere near as good as they should be, so I changed all the UUID’s by hand, making sure no reference to the source datastore remained. As there were only 15 VM’s to be moved in this disk chain, it only took 10 minutes. I do urge you to use sed if you’ve got a lot of VM’s to move.

Next, I needed to access the database and find all records of the source datastore, the records of the VM’s being moved and change all that. So I fired up the SQL Server Management Studio Express tool, and connected to the database. I prodded around the various tables. The following tables were of interest:


I noted the datastore_id of the source and target datastores. I didn’t change anything.


For each dir_id on the source datastore , I changed the datastore_id from the source ID to the target ID, so Lab Manager knows about the manual move of the files from the source datastore to the new datastore.


I deleted all the entries relating to the dir_id’s that were actually moved and where I changed its datastore_id in dbo.FsDir, so Lab Manager wasn’t aware of the manual move and previous problems with SSMove were solved.


In this small how-to, I showed how you can manually correct problems caused by SSMove. You can extend this write-up quite easily to never even having to use SSMove, but doing the migration completely by hand. Just make sure every configuration / VM is undeployed (mind the state in which you do this: I prefer clean shutdown (‘discard state’), not a pause (‘keep state’), so the configurations are easier to start up on the new ESX-hosts if you are also migrating to a new processor architecture, like I did in this migration). Then, manually move all the files in the ‘lm’ folder inside the datastores to their new location using either the Datastore Browser in the vSphere Client or the ‘mv’ command inside the Service Console. Record the UUID’s of the source and target datastore, edit the VMDK descriptor  and VMX files (please, use ‘sed’!) and hack away at the dbo.FsDir table inside the database, using information from the dbo.Datastore table. Check if there are any errors in dbo.FsDirMoveError, correct them and delete any records inside this table.