v6 Replication failing with "unable to access <vm>.vmx file"

[bbowden]

Migrated over to v6 and I can't seem to get a new replication job to complete.

Set up:
Source Host ESXi 4.1, Direct Attached Storage
Target Host ESXi 4.1, iSCSI storage
Transport mode: network

Just a default install of v6, so all Veeam components are on a physical, windows 7 host.

When I run the replication job, it creates the target VM, registers it, reconfigures it with the Guest drives, and then fails with the error:
Discovering replica VM Error: Unable to access file [datastore] server_replica/server.vmx
Error: Unable to access file [datastore] server_replica/server.vmx

However, if I browse the target datastore, the .vmx file is there.

If I retry the job, the only difference is that it deletes the target VM first, then goes through the same steps to failure.

I do have a legacy replication job that replicates a different guest in the opposite direction which works just fine.

I'm guessing that it might have something to do with the new proxy setup, but this is as vanilla a set up as you can get: 2 esx hosts with (the equivalent of) direct attached storage and one physical Veeam B&R server with default install, then a simple replication job configured by the wizard. I just want to keep a copy of the guests on one esx host on my other esx host.

I have opened case# 5159839 with Veeam, but haven't heard anything back and I really need to get this replication working.

[bbowden]

An additional piece of information: I expanded the column in the vSphere client showing the step that is generating the error. It is trying to create a snapshot of the non-running replica that it just registered. What?

Also should state, the whole job only takes about 5 minutes so I know my guest is not being replicated even though the files show up in the target datastore.

[Gostev]

I have opened case# 5159839 with Veeam, but haven't heard anything back

Hi, I can see on your account that you have "Standard" support on your account. According to the Veeam support policy, standard support is only provided Monday through Friday. You have opened the support case on Saturday, and thus should not expect to be contacted earlier than on Monday.

This is not a known issue that I am aware of, and unfortunately we cannot assist with troubleshooting technical issues over forum, as this requires full logs research by dedicated support staff (as explained when you click New Topic). Please, continue working with our support on this.

Creating snapshot on replica VM is normal, since this is how v6 replication works (it stores restore points as snapshots, please review FAQ for more details). I would probably start troubleshooting from looking at permissions on account vCenter is added with to Veeam B&R, tried to create a snapshot on replica manually, etc. Thanks.

[-Gertjan-]

Migrated over to v6 and I can't seem to get a new replication job to complete.

Set up:
Source Host ESXi 4.1, Direct Attached Storage
Target Host ESXi 4.1, iSCSI storage
Transport mode: network

Just a default install of v6, so all Veeam components are on a physical, windows 7 host.

When I run the replication job, it creates the target VM, registers it, reconfigures it with the Guest drives, and then fails with the error:
Discovering replica VM Error: Unable to access file [datastore] server_replica/server.vmx
Error: Unable to access file [datastore] server_replica/server.vmx

However, if I browse the target datastore, the .vmx file is there.

If I retry the job, the only difference is that it deletes the target VM first, then goes through the same steps to failure.

I do have a legacy replication job that replicates a different guest in the opposite direction which works just fine.

I'm guessing that it might have something to do with the new proxy setup, but this is as vanilla a set up as you can get: 2 esx hosts with (the equivalent of) direct attached storage and one physical Veeam B&R server with default install, then a simple replication job configured by the wizard. I just want to keep a copy of the guests on one esx host on my other esx host.

I have opened case# 5159839 with Veeam, but haven't heard anything back and I really need to get this replication working.

Did your source vm have an excluded disk?

[sacd]

Hi,

I've recently upgraded from v5 to 6.0.0.164 on both my production and DRP Veeam/vsphere servers. I can backup fine, but replication of our SQL VM's fails with this exact issue. We have independent:persistant disks which are excluded from the backup. I've logged a call with support, and have recieved the response below

"After looking at your configuration I see that you are using independent disks. VMWare can not snapshot these disks so we are unable to make a backup. You would want to power down your VM when you have the ability and uncheck independent. That will enable you to snap the VM and make a backup."

Frankly I'm disapointed with this response as A). The backup actually works fine, it's the replication job which is the issue. B). This worked fine in version 5. I'm afraid I find Veeam support lacking for such a great product!

[Vitaliy S.]

Hello,

This answer doesn't make sense to me either, you shouldn't convert or uncheck independent disks from the backup/replication job to make it work. Independent disks are automatically excluded from VM snapshots and shouldn't affect vmx file accessibility.

What is your support case number?

[sacd]

My case number is 5169554

Thank you!

[Ben Milligan]

Hi - I've checked on your issue and we will be following back up there in the case. The error actually looks to be snapshot related on the replica, and not the independent disks. We apologize for any confusion there and will coach the engineer on this mistake. Please try creating manual snapshots (then deleting them) on the replica servers that are failing. Please let us know in the ticket the results.

Thanks!

[sacd]

Thanks very much. I'll reply via case related email.

[sacd]

Hi Ben,

I've replied to Veeam support via email, but just FYI, these Replica VM's do not exist for me to snapshot. After the upgrade I removed all replicas. The reason being, the old v5 job was refered to as a "legacy replica job" so I thought it best to start again.

Also, if i attempt to "restore entire VM" and redirect to the DRP infrastructure, it errors out with the same error.

Anyway, thanks for your feedback.

[Ben Milligan]

No problem, I'm certain we will be able to resolve this for you.

[sacd]

So, even with VEEAM support (which has been great), I've not been able to resolve this issue of replicating our 2 SQL server VM's - needless to say very frustrating. Anyone heard of or even better, been able to reolve this issue?

Regards,
Dan

[tsightler]

Please make sure that your Veeam server and any proxies can resolve your ESX hosts by name.

[wasc]

I know this thread has been idle for over a month, however I had a similar issue myself and managed to resolve it (a google search directed me to this thread).

My scenario was as follows.
Clean install of Veeam 6 (no upgrade from 5).
Creating a new replica job with seeding.
I was able to create the initial backup job ok (after a bit of difficulty), but when running the first replica job to import the seed, it failed with the same error message (unable to access <vm>.vmx)

I believe this isn't a bug in veeam as such, however it is something that can be fixed in a Veeam patch so hopefully a Veeam employee will see this and submit an enhancement request.
In my particular case, the source VM for replication had a 256Gb Hard Disk, on a VMFS 3 datastore with a 1MB Block size - in order words the virtual hard disk was at the maximum allowable size. Whenever you tried to snapshot the source VM, the snapshot failed. We resolved this by following this vmware article -> http://kb.vmware.com/selfservice/micros ... Id=1012384

Specifically we edited the vmx configuration file of the virtual machine to add in the "workingDir" parameter to repoint the working snapshot directory to a datastore with a larger 2Mb blocksize.

This allowed us to snapshot the source vm, and Veeam was then able to take the initial seed.
When running the replica job to import the seed, all the VM's imported except one - the same one we struggled with. You cannot snapshot it. Eventually i found that when Veeam recreated the replica copy of the VM, it preserves the workingdir parameter, and therefore the replica version of the VM is trying to use a volume that doesn't exist. Removing the workingdir parameter allows the snapshot to complete, although I suspect veeam will simply notice the .vmx file has been modified and will therefore add the workingDir parameter back in.

To play it safe, i'm going to migrate the source VM to a different datastore and then start again, i.e. reseed that virtual machine.

Longer term, it would be good if veeam was able to detect if the VM has the 'workingDir' parameter set, and if so, alter it as part of the replica process.

[sacd]

Brilliant! We are in the process of going to upgrade to Vmware ESXi 5.1 and Veeam 6 - so i'll see what happens then.

Nice work! Glad you got yours sorted.

[Gostev]

VMware ESXi 5.1 is not released yet (and is not supported by Veeam 6 anyway).