ESX Post script won’t run when placed in the /tmp

 VMware
Mar 292010
 

While creating a deployment script for ESX using UDA (Ultimate Deployment Appliance) I found something pretty annoying which took some time before I figured it out. While creating my post script, I thought to create it in the /tmp folder. Since the /tmp directory is IMHO just a temp directory I figured that it would be the best place. Also, because I had to install 32 ESX hosts, I had no plans to do this manually. 🙂

Anyhow, In this script I would create just the VMkernel port for VMotion. The script would be run only once during the first boot. But somehow it didn’t run. After googleing and searching forums I finally found this article from VMware:

User-created files in the ESX /tmp directory are deleted with each host reboot
If you or the users you support store temporary files, such as application-generated log files, in the ESX /tmp directory, you will lose these files each time the host reboots.

Workaround: Do not use the ESX /tmp directory to store user-generated files and directories.

So… for some reason the VMware team “decided” to clear out the /tmp directory. Don’t know why though. However, after changing the path it worked flawlessly. 🙂 I don’t know if this will be fixed in the future but I do know this is something to watch for. During some searches, I noticed it worked in previous versions of ESX, however I don’t have any experience with that. Anyhow, sometimes I shouldn’t be lazy and just read the release notes. Even if they are huge. 🙂

Installing VMware vCenter and VMware View Composer 2 on Windows 2008 x64 with a remote SQL database

 VMware
Mar 272010
 

Last week we started building our lab. Since it’s isolated with it’s own internet feed we thought that it would be a good idea to access it using VMware View 4 over the internet. However, since we prefer using Windows Server 2008 over Windows 2003 we were not sure if we could use this for VMware View Composer 2.0. Somehow we couldn’t find this in the documentation so we started to test this out.

First we installed Windows Server 2008 x64 Enterprise Edition. Of course, this was installed perfectly on our physical server. The next step was installing our vCenter server. Ok, here the problems started. We have a SQL server 2008 instance hosted on another server and we wanted to use this database server. Well, for this we needed to create an ODBC connection. No problem… right? Well, not quite. When you are using a 64-bit edition of Windows you need to make sure you create a 32-bit ODBC connection. Although the process of creating such ODBC connection is pretty straight forward, you can’t use the ODBC shortcut located in the administrative tools.

Instead, you need to use the version located here: %systemdrive%\Windows\SysWoW64\Odbcad32.exe. Although it seems logical that you have to create a system DSN and not an user DSN. However, in our case this was not the only thing we needed to change. With Windows server 2008 x64, the included SQL driver is too new. If you are trying it like we did, you will get this error message: “DSN is pointing to a unsupported ODBC driver.” This is described in this document from VMware. Although it stated that the SQL driver is outdated, the file date from the driver which is included by default is actually newer then the one you need to download. 🙂

So after we downloaded and installed the correct SQL driver (called SQL Native Client 10), we where able to create the correct 32-bit system DSN and finally we could install vCenter Server.

The next step was installing VMware View composer 2 which is an optional component of VMware View. However, since it makes it possible to use linked clones (and also since I like playing around a bit) I thought “let’s install it!” The requirements of this product is that you have to install it on the vCenter Server and it needs its own database. Well, no problem. We created a new database and we setup a new ODBC connection just like we did with the vCenter Server installation. A 32-bit System DSN with the same SQL driver. However during the installation somehow it didn’t see any DSNs. At first I was a bit stumped. But well, it isn’t my first issue, so I stopped the installation process and deleted the newly created 32-bit System DSN. Again I created a new System DSN, but this time a 64-bit DSN. I restarted the installation process and VMware View Composer 2 was finally able to use the DSN

I will probably continue configuring our new lab next week, if I have some spare time. 🙂

 Newer Entries