Restoring to alternative host with WorkingDir set static

[resruss]

Hi all,

I've run into an issue while trying to create a replica on an offsite host, using Veeam B&R 6.5 and vCenter / ESXi 4.1 and 5.0 (different hosts)
When restoring to a different host, we get an error during Creating Snapshot, unable to find vmx file.
After some serious troubleshooting, I've realised the issue is that we've set the workingDir (due to snapshot and VMFS3 blocksize limitations) to a different datastore.
On the host we're trying to restore to, that datastore doesn't exist.

Changing the workingDir at this stage isn't an option, I'm just wanting to clarify if there's a trick when it comes time to run the restore job to a different host, if we can override or ignore the workingDir parameter and have it store with the VM.

I'm not too concerned about this being done automatically for replicas, at this stage, if we can successfully restore to a different host in a seperate location, that's enough to make me happy for the time being.

I imagine it's probably something that needs to be edited in the vbm file, registry change or PowerShell command

Has anyone run into this before?

[Vitaliy S.]

Hello,

Since replication jobs will always override changes you've made on target VM replicas (config change etc.), not sure it is possible to adjust this setting via PowerShell, but I will double check. Currently, the only way to resolve it is to either connect the datastore you've specified as a workingDir parameter or create additional datastore with the same name on the target host, might also do the trick.

Thanks!

[dellock6]

Any chance to upgrade the remaining 4.1 hosts to 5.0, so you can upgrade also VMFS to version 5 and get rid of block size limitations?

Luca.

[resruss]

Thanks for the responses guys, appreciate you taking the time to respond!

@dellock6:
Upgrading the host and datastore isn't really an option, upgrading rather than formatting a new datastore as VMFS5 would retain the existing block size, right?
We'd need to create a new VMFS 5 datastore, migrate the guest, recreate the old datastore as VMFS5 and migrate the guest back.

@Vitality S
At this stage, I'd be happy to forget replicas and have a single restore to a different host outside of the vCenter to prove restoration to a different host.
Anyone know of a way to edit / tweak the restore job to default the workingDir only for the restore job.

[dellock6]

You keep the underlying MBR allocation table after the upgrade until your datastore is smaller than 2 Tb, after that it is automatically converted to GPT. In any case, the block size is normalized to 1 MB regardless the initial size of the VMFS3 datastore, so even upgraded VMFS datastores will not have anymore the problem with block size limits.

Luca.

[claudiofolu]

Hello everybody
We have some VMs with workingDir parameter changed to point to other datastore.
We now want to replicate those VMs to a secondary site where that datastore doesnt exist.

What would be the workaround this?

[foggy]

No workaround is required. Replica VMs will not have workingDir parameter in their configuration file, snapshots will be created on the datastore where VM disks are located or where vmx file resides (depending on vSphere version).