{"id":447,"date":"2013-05-24T15:48:05","date_gmt":"2013-05-24T21:48:05","guid":{"rendered":"http:\/\/www.ecimulti.org\/blog\/?p=447"},"modified":"2013-11-25T18:02:39","modified_gmt":"2013-11-26T00:02:39","slug":"making-vmware-update-manager-5-1-1-work-with-sql-2012","status":"publish","type":"post","link":"https:\/\/www.ecimulti.org\/blog\/?p=447","title":{"rendered":"Making VMware Update Manager 5.1.1 (and 5.5) work with SQL 2012"},"content":{"rendered":"

06\/07\/2013 – UPDATE: A reader commented, and this is still an issue with 5.1.1a.<\/strong><\/p>\n

11\/25\/2013 – UPDATE: Thanks to user comments, VMware has finally published a KB to this issue: <\/a>http:\/\/kb.vmware.com\/kb\/2050256 also users report (as does the KB) this is an issues on 5.5.<\/strong><\/p>\n

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.<\/p>\n

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. <\/p>\n

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:<\/p>\n

\nmem> 2013-05-24T14:18:25.299-07:00 [02472 info ‘VcIntegrity’] Logged in!
\nmem> 2013-05-24T14:18:25.611-07:00 [03288 error ‘Default’] Unable to allocate memory: 4294967294 bytes
\nmem> 2013-05-24T14:18:25.720-07:00 [03288 panic ‘Default’] (Log recursion level 2) Unable to allocate memory\n<\/p><\/blockquote>\n

I 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.<\/p>\n

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.<\/p>\n

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.<\/p>\n

Till next time\u2026<\/p>\n","protected":false},"excerpt":{"rendered":"

06\/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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[42,54,91],"tags":[85,94,93,84,92,55,86,95],"class_list":["post-447","post","type-post","status-publish","format-standard","hentry","category-vmware-esx-esxi","category-vmware-vcenter","category-vmware-update-manager","tag-panic","tag-sql-2012","tag-sql-native-client","tag-update-manager","tag-update-manager-service-stops","tag-vmware","tag-vsphere","tag-vum"],"_links":{"self":[{"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/447","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=447"}],"version-history":[{"count":12,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/447\/revisions"}],"predecessor-version":[{"id":491,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=\/wp\/v2\/posts\/447\/revisions\/491"}],"wp:attachment":[{"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=447"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=447"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ecimulti.org\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=447"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}