workingDir and Replication

[topry]

If I set the workingDir to a different dedicated LUN from the default and replicate that VM, will it require editing of the .vmx and re-importing the VM into inventory to get it to work, since that LUN would not be accessible to the replication target?

Since both servers are managed by the same VirtualCenter the datastore names cannot be duplicated - but if the original ESXi host is offline, I suppose we could drop it from the datacenter and then rename one of the datastores to match. But, if we wanted to then replicate the data back to the original host, we would face the same dilemma.

[Gostev]

I believe the job will update workingDir automatically, and set it to the target datastore.

[topry]

Thank you for the reply - I have tested it and that is not what happened in my test.
I shutdown a 2008R2 test system.
Modified the .vmx, adding the workingDir param setting it to a different LUN
Removed the VM from Inventory, re-added.
Started the VM to verify the workingDir was mapped correctly - the .vswp and snapshots were created on the specified workingDir LUN.
Created a replication job and replicated to another host.
Checked the .vmx on the replicated vm - and it was the same (workingDir still set to LUN on source).
Attempted a poweron of the replicated VM and it failed, with the error 'The virtual machine cannot be powered on because its working directory is not valid....'.

If I edit the .vmx, removing the workingDir entry, remove/readd to inventory then it does of course work, but subsequent replications do not see that VM as the same one (I'm assuming the UUID is changed when removed/readded to inventory), so anytime we would test our replicated VMs. we would be faced with pushing the entire image over the WAN, which isn't possible for us.

It would be a nice feature if the replication job could remove that .vmx parameter prior to registering the VM with the target host.

[Gostev]

I agree. I will have a bug logged. Thanks.