Category Archives: Vmware

Here are some notes on a recent migration I completed for vCenter. The source machine was a Windows 2008 R2 Server box that was running vCenter 5.1 and the new machine was a Dell R320 running Windows 2012 Server. I initially tried to install vCenter 5.1 on the Windows 2012 server, but it had a lot of errors with the install of the Single Sign On Service. Even with the latest version of vCenter 5.1, there are major issues when installing it with an existing vCenter database. I tried creating users from scratch in SQL Management Studio, installed SQL 2012 and 2008 R2 to no avail, and created ODBC system connections to no avail. There appears to be some issues with the way vCenter 5.1 communicates with the SQL server in Windows 2012.

The easiest solution to this was to upgrade vCenter on the source machine to vCenter 5.5. Using this vCenter 5.5 tutorial, the in-place upgrade to 5.5 worked well. To make things easier with the install, use the same password for the two accounts: vCenter 5.5 uses the username of administrator@vsphere.local, while vCenter 5.1 uses admin@system-domain for the username.

VCenter 5.5 works great on Server 2012 as I was able to install without any errors using this guide on the VMWare site. I installed SQL 2008 R2 on the new server in order to ensure that the database backup/restore wouldn’t have any issues. You still will need to create the 64-bit ODBC driver sources in the system in order to have VCenter communicate with the database. After the databases have been restored on the SQL server, proceed with the installation and make sure you select the existing database option to keep the old data.

Once vCenter is installed on the new machine, you will need to reconnect all vSphere hosts with the username/password. If you notice that the host initially connects and then disconnects, double check the firewall setting on the vSphere host to ensure the heartbeat check is able to pass through.

Share this:

In order to reset the vCenter Single Sign On Master Password running on a Windows server for the admin@system-domain user, you will need to have local admin access and SQL Server Management Studio installed. I initially tried using this method on VMWare’s website to reset via the command line, but got an error “ERROR: Failed to decrypt field com.rsa.db.user”. There is a workaround where you run a SQL command to reset the password to a known passphrase.

You will first need to open up the SQL Server Management Studio. Select the “VIM_SQLEXP” server name. Expand the Database folder tree, right click the RSA database and select “Tasks->Back up”. Backup the database to a local file. This is just in case the database somehow breaks when changing the password.

Run the Query in SQL Server Management Studio – RSA database. Once the query is successful, the admin@system-domain user password is now set to VMware1234!

To reset the password to something more secure, run the VMWare Web Client (https://MYSERVER:9443) with the new admin@system-domain credentials. After logging in, click on the “admin@system-domain” link on the top and select “Change Password”. Make sure it follows the proper password policies — 8 min characters, 1 special character, etc. Logout and your new password should work.

Share this:

If you encounter the following error while installing vmware-tools in Fedora:

Searching for a valid kernel header path…

The path “” is not valid.

You will need the following packages installed:

gcc make kernel-headers kernel-devel

The trick is that you will need to perform at least two reboots before the vmware installer will actually find the kernel header package. You can verify the kernel install using “rpm -qa kernel*”

yum install gcc make kernel-headers kernel-devel

yum update

Reboot (shutdown -r now)

Run vmware-install.pl (Ex. /tmp/vmware-tools-distrib)

It will probably not find the kernel header path this time around. Cancel the installer if its unable to find it again.

Reboot (shutdown -r now)

Run vmware-install.pl again. I’m usually able to install vmware-tools after the second reboot

DISCLAIMER: This is for informational purposes only. We are providing absolutely no warranty for this information. Use this information at your own risk. Always perform upgrades on a test server before production and always have a full backup of the system.

If you are migrating from one guest host to another using VMWARE and have problems with reusing the IP address from the old host, VMWARE may be binding the IP address to a MAC address. Even with the old server off, I was unable to get the new server to bind with the original IP address.

The fix is to create/set a network adapter on the new server with the MAC address of the old server. After setting the MAC address on the new box to the original NIC MAC address, I was able to get full connectivity with the old IP address.

This will only work if both hosts are on the same VLAN, the original host was using a flexible network adapter, and on the same VMWARE server cluster.

Share this:

VMWARE Server 2.02 has been released October 27, 2009. It includes a few important security updates for VMWARE Server. If you are running a Linux server with VMWARE server 2.01, I strongly suggest to upgrade due to the “Directory Traversal Vulnerability” — which may allow for remote retrieval of any file from the host system.

Security Fixes with VMWARE 2.02

New:Exception handling privilege escalation on Guest Operating System This release addresses a security vulnerability in exception handling. Improper setting of the exception code on page faults might allow for local privilege escalation on the guest. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2009-2267 to this issue.

New:Directory Traversal Vulnerability on Linux-based hosts This release addresses a directory traversal vulnerability that is present on host systems and that may allow for remote retrieval of any file from the host system. In order to send a malicious request, the attacker will need to have access to the network on which the host resides. The issue is present on Linux-based hosts only, not on Windows-based hosts. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the name CVE-2009-3733 to this issue.