Virtualization
Moving my VMware vCenter 4.1 and VMware Update Manager database
I have already explained that i have a local vSphere setup running as a test environment. Of course i use vCenter for that, not much use to have a cluster running and not using vCenter ;).
As this setup is a small environment, i chose to use the MSSQL Server 2005 Express which is bundled with the vCenter 4.1 U1 installer. But with the release of vSphere 5, vCenter no longer supports MSSQL Server 2005 Express.
The solution? Install MSSQL Server 2008 R2 which i have a license for because of my Microsoft Action Pack Subscription and move the database of vCenter 4.1 and Update Manager to this new DB server.
So in one of my Windows Server 2008 Enterprise VM’s i installed the SQL server and set it up to contain the databases for VMware Update Manager and VMware vCenter.
First up: Update manager!
Moving the database to the new server was rather easy. Steps i took:
- Allowed mixed authentication
- created a user with sysadmin rights, just for the ease of it
- Made a database called VIM_UMDB
- Set the compatibility to 90 (MSSQL 2005)
- Stopped Update Manager
- Took a backup of it’s database
- Restored it to the VIM_UMDB on the new server (overwrite everything)
After this step something went wrong, it took a while before i figured out the problem was with the Database connector. It seems so logical now, but it took me a while to figure it out. So a little guide after you moved the DB:
- Install the MSSQL 2008 R2 Native Client, this also installs a 32bit driver. You can download it from here (search for Native Client)
- Open odbcad32.exe (C:\Windows\SysWOW64\odbcad32.exe) , not the regular ODBC configruation. This is where i went wrong, you need to open the 32 bit version to add a 32 bit connector.
- Add a new connector with the SQL Server Native Client 10.0 driver and name it something you can remember
Now the only thing we need is to change the configuration of the Update Manager so it knows to use the new database connector.
- Just open C:\Program Files (x86)\VMware\Infrastructure\Update Manager\vci-integrity.xml
- Find the <database> tag
- In the <dbtype> tag, fill in: SQL Server Native Client 10.0
- In the <dsn> tag, fill in the name of the DB connector you created.
- Save the file
- Restart the Update Manager
To be sure, connect to your vCenter server with the client, and see if you get an error about the Update Manager. If not, check if you can scan a host or something. If everything works, great, you successfully moved your Update Manager database!
Next: vCenter Database
This should be a bit easier cause VMware has a Knowledge Base article about it (and another one). And my experience with the Update Manager database did help. Basically the first 10 steps (1-7 and 1-3) are the same, except you just create a normal DSN (so don’t use the 32 bit odbcad32.exe). Next steps:
- Uninstall vCenter… Yes, indeed, uninstall it.
- Reboot your vCenter server
- Reinstall vCenter
- During the install select the newly created database connection.
- Don’t forget to recreate the statistics rollup job in SQL server (KB Article)
Setting up a new VPS
Today i decided to get a new VPS from Shift to the cloud, a new project from Stone Internet Services (@stoneis). Stone IS has been a choice for webhosting and domain registration for me and my clients for years, and i have always been happy with their service.
In the past i have always counted on ULYSSIS for my personal hosting, as i have been vice-president of this organisation and have a free account because of that. But lately, i realized that, although their service is incredible for an organization of volunteers, it is not as open and free as having an own server at your disposal.
Ordering the server was rather easy, i only had an issue with the payment system, but i hope it was just a fluke and not something others experience. At least the service desk helped me out pretty quick. I opened an issue last night and it was fixed by the time i woke up this morning, on a Saturday.
After i got the base VM (Ubuntu 10.04 LTS) running i started to configure it by installing some base packages like apache, openssl, php5, suphp, … After a while i noticed it didn’t have the promised IPv6 address, so i opened another support ticket, and it took them about 15 minutes to fix it. If that’s an indication of response time for the Best Effort SLA, i am impressed.
When the IPv6 address was enabled, i did get into trouble with Apache. Everytime i wanted to start it, it crashed with the following error:
|
1 |
[Sat Dec 03 12:48:52 2011] [error] (9)Bad file descriptor: apr_socket_accept: (client socket) |
Whenever i disabled SSL, it worked fine. After a few google searches, i came to the conclusion that the automatically generated SSL certificates became invalid with the change of network interfaces/addresses. I fixed that quickly by creating a new certificate, and my own Certificate Authority . If you need some info on how to do that, you can find a good tutorial on the website of Paul Bramscher.
And now that this blog is moved to the server, we’ll see how it goes. Next step will be to move my Symfony2 project from my development environment (VM on a personal vSphere setup on two local servers) to this server, so i can more easily access it from anywhere.
Other plans include setting up a monitoring system (Nagios) to monitor my internal network and some servers and environments of my smaller clients (who do not have the resources to implement it locally). This kind of monitoring system is already running on my local vSphere farm, but that means it uses my personal internet connection, which is just a commercial connection (once or twice a month it goes down in the middle of the night for 10-15 minutes).
