Tricking around in ESX VirtualCenter
Virtualization is great…it’s the current hot item in IT. Everyone is doing it; it’s the future of datacenter consolidation.
…it’s my current project.
After a few days of research, some CBTs, and a few meetings, we finally decided to start implementing our grand master plan. Brand new 16 core server with 128GB RAM…check, ESX licensing…check, sanity…check.
After deciding on our virtual network and disk architectures, we finally went to work. VMware is ungodly easy to setup, it’s almost scary.
Next step was getting our VirtualCenter server up and running, and this is when the fun begins (and by fun, I really mean WTF). In the title of the post, I mentioned something about “tricking” around in this particular portion of the setup process, so allow me to explain.
VirtualCenter is basically just a consolidated ESX host management solution. Instead of connecting to each ESX host individually to manage it, VirtualCenter (VC from now on) allows you to manage all your hosts from one area. In VC, you can make ESX clusters, manage Distributed Resources, manage VMotion, and a whole bunch of other goodies. It runs on top of a basic Windows server, uses Active Directory for authentication, and is supposed to make everything nice and easy. Indeed, it does; the interface is great, and manageability is superb…it makes my job all that much easier.
Installation is pretty straightforward, and after clicking “Next” a few times for the VI Client and for the VC server, you think you’re golden. Of course, there are some steps you have to perform as pre-requisites for VC.
First, you need to create a database for it. Well, I’m lying, you don’t particularly HAVE to create a database for it, since it would offer to install MSDE in the same step, but we have a SQL 2005 Cluster…why not take advantage of it? So, created a database, and assigned a domain user myDomain\esxdb as db_owner to it.
Next, create a system DSN to point to that database using NT Authentication. Make sure you use the SQL Native client since it’s SQL 2005, and you’re ready to roll.
Finally, during install, provide the installer with the DSN name, the username, and the password that it will need to connect to the database.
Wait wait wait…so what about this trickery you keep talking about?
Let me get to that!
Next up…installing the Update Manager and the Converter. Go through those steps…and wait…it tells me that the VirtualCenter server is not running? I JUST INSTALLED THE DAMNED THING…on a brand new clean server, no less.
Ok then…I go to the Services menu and try to start it manually….fail. Fail? FAIL?!
Looking through logs (which are in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\Logs …yea don’t ask why they are there, they just are), I see this:
[2009-04-01 16:20:21.613 'App' 1784 error] ODBC error: (28000) – [Microsoft][SQL Native Client][SQL Server]Login failed for user ‘NT AUTHORITY\ANONYMOUS LOGON’.
[2009-04-01 16:20:21.613 'App' 1784 error] Failed to intialize VMware VirtualCenter. Shutting down…
[2009-04-01 16:20:21.613 'App' 1784 info] Forcing shutdown of VMware VirtualCenter now
Now wait a minute…why the hell is it trying to login to the SQL server as anonymous when I damned clearly provided a username and password for it, and I’m logged into the VC server as a domain admin, so even if it was passing active credentials, it should work. However, it was not.
So ok…what if I go back to the DSN and specify credentials there. Nope, can’t do that…it’s either NT authentication (which does not let you pass credentials), or SQL authentication (which does). Putting domain credentials into the SQL authentication fields result in a whole bunch of fail.
Ok then, next step: create a local SQL user, and use that instead. So I create a local user called esxlocaldb on the SQL server, make that user the db_owner, and re-run the installer for VC. I give it the credentials of the esxlocaldb user (after changing my DSN to use those SQL credentials, obviously), and it comes back and tells me that the credentials are incorrect. I doublecheck everything, do a test in the DSN config window, and everything is dandy…but the VC installer simply wont work.
So now, the trickery begins. In order to install this F-ing thing, I basically had to have both the esxlocaldb user as db_owner AND the domain\esxdb user as db_owner to the ESX database. For the DSN, I gave it the esxlocaldb credentials using SQL authentication, but for the ESX installer, I gave it the domain account. This seemed to work flawlessly.
I think that the installer is just wacked…it uses the DSN credentials to query the DB, but VirtualCenter actually requires a domain user to have access to it. Really, makes no sense to me, but we basically tried everything else. Every other possible combination of database rights and DSN configurations.
Makes no sense to me, but it works now…if anyone has any comments on what we may have missed, I’m all eyes and ears.
