VMware Cloud Community
loge
Contributor
Contributor

vDR reports -3942

Hi,

i am trying to backup a guest which hosts a windows xp installation. Setup is quite easy, one hdd with 10 gigs. When i want to backup that guest with vDR, i am getting:

"Trouble reading files, Error -3942 (deletion of snapshot failed)"

(translated it from my german localized error log)

The result is quite weird in the guest folder. See the attached picture. Normally i only have one vmdk, now i have a lot more and even more weird is that the vmx now contains the .....0000002.vmdk as the primary hdd which fails when i want to reboot my guest. Seems totally freaked out ....

Thanks for any help. The snapshot is NOT shown in the snapshot manager.

Marc

Tags (3)
0 Kudos
6 Replies
admin
Immortal
Immortal

Some suggestions

1) Can you verify the block sizes of the VMFS volumes that this Windows XP guest's vmdk is located? Is the VMFS block size equal or smaller than the VMFS volume for the VDR appliance's vmdk?

2) Does the same problem occur on other VMs being protected by VDR? Or issue unique to this one VM?

3) A few "delete snapshots" KBs to note

http://kb.vmware.com/kb/1002310

http://kb.vmware.com/kb/1007849

http://kb.vmware.com/kb/1006847

0 Kudos
RParker
Immortal
Immortal

.. you can do ALL that.. OR

Reboot the appliance.

0 Kudos
admin
Immortal
Immortal

I get as frustrated as the next guy when the recommendation is to reboot the appliance....the downside is we loose visibility into whether the issue is

1) VDR

2) Storage (snapshot ,VMFS, hot add)

3) Something unique about the customer's vSphere environment

Hoping that being prescriptive will help isolate the issue, even at the expense of longer troubleshooting time.

0 Kudos
RParker
Immortal
Immortal

No loss in visibility, I can pretty much guarantee its the appliance. I have to reset at least once, sometimes 2 or 3 times a week, so I am VERY familiar with the shortcomings of VDR.

So I am not merely an AOL tech recommending you simply reboot your PC becuase you can't connect to the internet.

Reboot the VDR fixes the problem EVERY time.

The storage isn't the issue, if it was the VM's would be having issues but they are not. ONLY the VDR has issues, thus rebooting fixes the problem. VDR is a 1.x product, it's new, it has so many bugs, I can't keep track, they did improve it with 1.2, but it still has a LONG LONG way to go to be any type of competition for other more mature products.

We saved some money.. now we have to settle for mediocre performance and remedial backups. As long as there is VDR my job is 100% secure.

0 Kudos
loge
Contributor
Contributor

Thanks for the quick replies. I will try to answer them, even though i will have problems with at least one Smiley Happy

1) I have 5 Linux Guests and 1 Windows Guest, only the Windows Guest fails, the rest are perfect

2) I have not rebootet the VDR appliance yet.

3) All guests (also VDR) are located on an OpenFiler SAN, attached via iSCSI

4) I even created a new Win VM and placed the HDD from the other failed Win Guest to it and tried backup, but error occured again. So it seems not to be a VMX issue.

5) backup target is a SMB folder to a non-virtualized Windows Server (where vSphere runs).

I am unsure how to answer the block size question. I dont even know how to check that. So before i reboot VDR, i would start helping debugging the issue.

Hope this helps.

0 Kudos
admin
Immortal
Immortal

Highlight the ESX host, choose Configuration/Storage (there maybe an alternate way via Inventory/Datastore). That will show you the list of datastores in table. When you highlight each datastore, it will show you the details of each datastore. Under formatting, you will see block size - the number will be 1, 2, 4 or 8. You want to make sure that the datastore that VDR is deployed on is resident on the largest block VMFS block size datastore, otherwise, snapshots will potentially fail

0 Kudos