-
Making VMware Update Manager 5.1.1 (and 5.5) work with SQL 2012
Posted on May 24th, 2013 No comments06/07/2013 – UPDATE: A reader commented, and this is still an issue with 5.1.1a.
11/25/2013 – UPDATE: Thanks to user comments, VMware has finally published a KB to this issue: http://kb.vmware.com/kb/2050256 also users report (as does the KB) this is an issues on 5.5.
My lab was getting pretty dirty, so I thought why not start from scratch with vSphere 5.1.1. I figured it was also a great time to refresh my old lab SQL Failover Cluster with Server 2012 and SQL 2012 too. I had been wanting to play with AOAG and the other new(er) toys 2012 had to offer anyway.
From what I can tell, technically vSphere is officially supported on SQL 2012??? Being the rebel I am, I pressed on undeterred by a support matrix anyway.
Everything went as planned during the vSphere Install, and I was pretty happy. Then it came time to get Update Manager working. I installed it as usual, creating the required 32-bit DSN using the SQL 11.0 native client (what comes with SQL 2012). It installed normally and worked for about 3 minutes. Then the Update Manager service started to die repeatedly. I checked out the logs in C:\ProgramData\VMware\VMware Update Manager\Logs, and I saw this:
mem> 2013-05-24T14:18:25.299-07:00 [02472 info ‘VcIntegrity’] Logged in!
mem> 2013-05-24T14:18:25.611-07:00 [03288 error ‘Default’] Unable to allocate memory: 4294967294 bytes
mem> 2013-05-24T14:18:25.720-07:00 [03288 panic ‘Default’] (Log recursion level 2) Unable to allocate memoryI was like oh, some sort of Java nonsense. I tinkered around a bit, looked in the VMware KB and Google. Nothing really seemed to help.
I started to wonder if SQL was the issue, so I bumped the Update Manager DB down to 10.0/SQL 2008 compatibility mode…. no joy. Then I installed the 10.0 native client from SQL 2008 R2 media, and recreated the 32-bit DSN. I started Update Manager back up and BAM …it seems to be stable for a couple days now.
If this wasn’t a lab I’d call VMware to complain, but alas it is lab. looked through the 5.1.1 release notes, and I don’t see anything about this? For the record, all other portions of vSphere worked fine with 11.0 native client, including SSO.
Till next time…
ESX and ESXi, vCenter, VMware Update Manager panic, SQL 2012, SQL native client, Update Manager, update manager service stops, vmware, vSphere, VUM14 responses to “Making VMware Update Manager 5.1.1 (and 5.5) work with SQL 2012”
-
Thanks for this. Worked a treat!
-
BRILLIANT!!! I Was experiencing the VERY same problem. I bumped up the RAM on my VC to see if that would help any allocation issues. Nothing. VMware’s own websites have very little in the way of this. What a life saver!
-
I’m happy so many people are finding this useful! I sent this in to VMware Support when I wrote it, so hopefully they’ll update a KB or something. 5.1.1a was release, and I haven’t had a chance to see if that fixes it.
-
Just installed 5.1 update 1a – update manager is not updated as part of this release unfortunately. Had the same issue, reverted to SQL native client driver which solved it. Thanks so much!
-
Confirmed that in 5.1.1a, with version 10 of the SQL Native Client but with database compatibility still set at the 2012 level, Update Manager stops crashing on startup. Interestingly, my Update Manager instance survived a lot longer than 3 minutes – it was a good few days – but the same symptoms hit it in the end and it wasn’t for coming back until I switched (*only*) the SQL Native Client version to 10.
-
I also had my servers (VC, VUM, SSO, etc) running for a few days. It wasn’t until I went in and configured VUM and set a schedule to download, and then rebooted the server, that I experienced the service crashing.
Installing the 2008 R2 Native Client and reconfiguring the DSN fixed the problem.
Thanks, I would have never figured that out.
S -
Hello, I installed the 2008 R2 native client, and recreated the DSN. Am still experiencing the same behavior. VMware still does not have a resolution for this. Anyone else not able to get the work-around to work?
Regards,
Brian -
Thanks for your blog, been searching for a couple of days for a solution. You need to tag this with “update manager service stops” for no apparent reason. Thought it was AV that caused it, rebooted VC about 5 times. Now it is working – thanks
-
Thanks for the advice on tag’s, I’ll add that one now 🙂
Still pretty shocked VMware doesn’t have anything posted up about this. Pretty clear from the comments we’re not the only ones who’ve struggled with this.
-
As of today there is no KB article about this problem.
Recreating the System DSN as SQL Server (the one provided with OS) has fixed the issue.
Thanks, this save me as lot of time, especially that the information in the logs is not obvious.
-
Thanks. Same issue. Fixed as per your article. Works a treat. Will hopefully stay that way too.
Cheers… 🙂
-
Worked for our lab. We originally installed SQL Native Client 11 and ran fine for several weeks. We noticed the failures start right around the time we brought up the DR site and put vCenter into linked mode. Possibly a coincidence, but worth mentioning. Deleted the SQL Native Client 11 and recreated with SQL Native Client 10. Immediately came back online.
-
I can confirm that this bug appears to still exist in 5.5, and that installing the native client from SQL 2008 R2 and recreating the DSN works!
Thanks for this.
-
Thanks – there is now a KB, although I found this first!
Leave a reply
-
