VMware Cloud Community
andreas190386
Contributor
Contributor

Can not create Snapshot another Task is already in Progress error - 3941

hi all,

I hope someone can help me by my problem, I have always gets these error when I want to take a Snapshot:

Another Task is already in Progress

When my Data recovery runs, I´ll get always these error:

7/3/2009 7:57:11 AM: Normal backup using Backup Job 1

7/3/2009 7:57:13 AM: Failed to create snapshot for ck1, error -3941 ( create snapshot failed)

7/3/2009 7:57:13 AM: Task incomplete

Thanks in advance best regards

andi

Reply
0 Kudos
13 Replies
schepp
Leadership
Leadership

Have you tried restaring the vCenter service? I've seen tasks getting stuck sometimes.

Reply
0 Kudos
GarethWilson
Contributor
Contributor

did anyone get a resolution for this ?

restarting vcenter services didnt kill the locked task, and i have alos downed the VDR applicanace but that still doesnt allow me to do anything with the vm.

Cheers in advance

Reply
0 Kudos
lauffen67
Contributor
Contributor

I have the same problem. Error -3941 (snashot failed). This append only with the same VM. All others VM are well backed up !

Other VM that can be backed up are Linux and Windows 2003 with VMware Tools integraly installed.

The VM that can not be backup up has VMware Tools partially installed (only deamon but no drivers... becauce GCC compiler was not installed)

Is there a work around ? Thnaks

Reply
0 Kudos
admin
Immortal
Immortal

We've managed to find one scenario where this may occur, and that is when a connection from the VDR engine to the Virtual Center is unexpectedly lost. A fix to properly handle this situation is in the works. In the meantime, you can validate if this is your particular situation by looking for the following message in the VDR engine's datarecovery logs (found in /var/vmware/datarecovery on the VDR appliance): "could not init object enumerator, error: 1306 (vcbAPI: unknown exception)".

Fletcher Glenn

Reply
0 Kudos
pym
Contributor
Contributor

It is happening to us as well, with VDR for vSphere. It happens for 3 of my 8 VMs and my guess is that it could be related to the fact that these three systems run SQL Express (MS-WSUS, Symantec AV Server and Symantec System Recovery).

Reply
0 Kudos
admin
Immortal
Immortal

Assuming you are already on VDR 1.1?

When you open up Snapshot Manager for this VM, is there any existing snapshot with datarecovery name?

A potential issues - VMFS Block size this V's datastore is larger than the block size for the datastore for the VDR appliance. This could cause snapshot and hot add issues if the vmdk being snapshot is larger than the supported size on the VDR's datastore

Reply
0 Kudos
pym
Contributor
Contributor

Hello Azmir and thank you for your feedback!

Yah! I am using 1.1. The VDR log states that VDR is at v1.1.0.707. Yet the plug-ins page tells me that VDR is at 1.1.0.27. I guess .707 is the backup appliance's version, while VDR is at .27.

No snapshot with a datarecovery name for the MS-WSUS VM, but there is a "test" snapshot which I tried to create before installing WSUS-SP2 (recently) since I couldn't get VDR to work on this system. No existing snapshots on the other 2 systems which managed to get only 1 VDR backup over the last 2 weeks (running every night between 18h & 07h).

The VMFS blocksize for the VDR appliance is larger than that of the VMs as I was trying to get a 1TB partitions for VDR (which is aparently its largest supported size). However, it's capacity is at 738GB (with 623GB free, right now), so as not to trigger the disk usage alarm set at 85%.

All 8 VMs are backed up to that same datastore.

Reply
0 Kudos
admin
Immortal
Immortal

Lets separate out the 2 problems - I would recommend opening up an SR to work through these issues

1) The WSUS VM seems to have unique issues - it cannot be backed up at all. Not sure what is going on here. What HW version is this VM? (VDR supports HW4 and HW7 VMs)

2) The other VMs backup the first time, but then stop (for no apparent reason)

I would troubleshoot #2 first. Note that if the dedupe store is not mounted or if integrity check fails, then backups cannot start. A few ways top verify

1) Under the Backup tab, the Backup Job should show the VMs not being backed up as being Out of Compliance

2) Look in Configuration/Logs and see if he Backup Job for these VMs even attempted. If it started, that means the scheduler is working. Scan through the logs for the last integrity check. If there is no trace that the backup job even started, then create a new backup job and see if it will start.

Reply
0 Kudos
pym
Contributor
Contributor

Good morning Azmir!

Re 1) I will open an SR for WSUS, but I'm going on Holidays until the beg. of Jan, so it'll have to wait. Trying to vMotion WSUS this morning to install U1 (and other patches) on its host, I got a "The operation is not allowed in the current state" message. Haven't had a chance to search the KB for this one yet. All the VMs are HW7)

Re 2) For one of the other two VMs (let's call it AV), the backup only worked the first time; for the 3rd VM (called Cent) , it worked only once two days ago, following its Host's being patched and updated to U1 (could be just a coincidence, but...). As it turns out, it also worked last night, so the problem might have fixed itself. The next few days will tell...

The interesting thing, is that WSUS and AV are both running on the yet to be patched host and were the only two VMs (of the 😎 to have been migrated from GSX to 3.5, then to 4.0. SO today, I will patch my last host. As well, neither of them can be vMotioned as described above.

Re 1) comment : You are right. It is showing this for both VMs, and only for them.

Re 2) comment : I got the error -3941 from that log. Three lines for the job, so it looks like the scheduler works just fine :

Normal backup using...

Failed to create snapshot...

Task incomplete...

Have tried your new backup job, as WSUS was originally within a job with more VMs. Now, it is on its own. AV is still in that larger job.

Last integrity check on the 22nd 7AM; next line about WSUS. *** It keeps trying to back it up even outside scheduled hours, but I only see this in the config/Log, NOT in the Reports ***.

I think we are back to only one problem, despite the fact that AV has worked once 2 weeks ago. Smiley Happy

At any rate, I will patch my last host in a few minutes and will test vMotion again.

As well, I will try VDR on WSUS & AV when they are OFF, to see if it works any better.

Thanks again for your help... will post the results...

Reply
0 Kudos
pym
Contributor
Contributor

Thus far, I have turned OFF the 2 VMs, vMotioned one of them, brought them to VDR compliance, and started two separate VDR jobs and all seems to be going fine. Of course, we'll see if all works as well once they are back ON. This will take the better part of the day as these VMs have a lot of data.

Reply
0 Kudos
admin
Immortal
Immortal

For the VM that cannot be VMotioned, take a look at this KB

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=101238...

Not sure , but worth checking.

Also, attempt to do a manual snapshot when VMs are powered on. Make sure to uncheck memory state and check quiesce guest file system option when attempting the manual snapshot since this will mimic the snapshot operation that VDR initiates.

Reply
0 Kudos
pym
Contributor
Contributor

Actually, everything worked out, including manual backups once the VMs were up and running and the vMotion of turned ON VMs. So I updated vSphere Server, Client, Converter, etc... to update 1 and then I could no longer log into VDR. It just never ends... that is why it is so much fun :-).

I did a reset and now it is busy removing a snapshot of WSUS (stuck at 95%). Anyway, time to go home :-). Will come back in the morning... and try a manual snapshot...

Thanks for all of your help...

Reply
0 Kudos
pym
Contributor
Contributor

Both VMs are still not in VDR compliance however (since they haven't run often enough, I gather), the backups seem to be done (although nothing since my manual ones yesterday).

Good enough for now! Will see in the New Year...

Happy Holidays all!

Reply
0 Kudos