Yellow Bricks

by Duncan Epping

VirtualCenter database

· ·

There has always been much discussion about the VirtualCenter database if it was important enough to back it up. Most people agreed that the information that the database held was not important. A datacenter and cluster could be easily reconfigured and all other settings were saved on the host. HA wasn’t even using VirtualCenter, and DRS well a day without DRS is something most companies could afford.

VirtualCenter 2.5 already contained a feature called “Distributed Power Management”, with this feature the VirtualCenter database became more important but still one could easily do without it. But VMware just released VirtualCenter 2.5 Update 2. This update contains a new feature for HA. HA will get it’s IP info straight from VirtualCenter instead of the /etc/hosts file or DNS. With this info HA fills up /etc/FT_HOSTS. This all of a sudden makes the VirtualCenter database and the VirtualCenter server more important than ever.

I guess it’s time to start building the VirtualCenter server in a different way. Going virtual might be the best solution for having a highly available VirtualCenter server and database. But what about actually backing up the Database, via a maintenance plan or a backup engine. In time the VirtualCenter database will only get more important, especially when for instance DPM evolves. I can imagine DPM will detect trends and switch servers on and off accordingly.

Anyway, the only message I wanted to get out is start backing up that database!

Cool feature of the VMware Converter plugin

· ·

How about backing up that dreadful application/server that you couldn’t or did not wanted to virtualize to your ESX environment? It could be useful to have a copy of a server that for whatever reason you did not virtualize. The new VMware Converter plugin for VirtualCenter gives you this option. You can create a reoccurring schedule for a p2v, you can even save several version of the converted machine. How cool is that! Seems like a great way to backup a machine!

How do I do this:

  1. click on scheduled tasks
  2. click new and pick “import a machine”
  3. select “physical” and enter the servers name/ip and username and password
  4. select the disks you want to import
  5. type a name for the VM
  6. select the destination host
  7. select a datastore
  8. select a network
  9. and schedule the task!

ESXi 3.5 Update 2 on a USB memory key

· ·

For those like me who would like to check ESXi 3.5 update 2 but don’t want to install on a local harddisk. Here’s a good pdf about how to install it on a USB memory key. It’s fairly easy and I just booted my IBM X61 laptop with ESXi.


In short:

  1. First get the following tools: 7-Zip(Free), WinImage(Demo)
  2. Download the ESXi ISO
  3. Open the ISO with 7-Zip
  4. Extract “install.tgz”
  5. Open “install.tgz” with 7-Zip
  6. Click on “install.tar”
  7. Browse to “usr\lib\vmware\installer\”
  8. Open “VMware-VMvisor-big-3.5.0_Update_2-103909.i386.dd.bz2”
  9. Extract “VMware-VMvisor-big-3.5.0_Update_2-103909.i386.dd”
  10. Open WinImage and go to Disk, click on “Restore Virtual Harddisk Image on physical drive”
  11. Select a physical drive
  12. Select “VMware-VMvisor-big-3.5.0_Update_2-103909.i386.dd”
  13. And click “yes” to write the DD image to the USB Disk

Done! For a more detailed procedure check the pdf above, it also includes screenshots!

High Availability change

· ·

I just noticed the following, when creating a new(!) HA cluster on VirtualCenter 2.5 Update 2 the default isolation response is set to “Leave powered on”. In other words, when your ESX host hasn’t got a network connection any more the VM’s remain on. This is a huge change because the default used to be “Power Off”.

Besides “Power Off” and “Leave powered on” there’s a new option introduced. And this is one I was looking for, “Shutdown VM”. Shutdown VM doesn’t just pull the cord, it tries to shutdown the VM in a decent fashion, via the OS.

ESX 3.5 U2 and HA error

· ·

Erik Zandboer just posted a topic on the VMTN forum about an HA error he received when he updates his machines to 3.5 U2. The error was one almost everyone has probably seen by now “could not contact primary HA agent”. This is normally solved by pressing “reconfigure for ha” or disabling and enabling HA. This wasn’t the case this time. after some research Erik discovered that the host file entry for the ESX host did not match the DNS name, one of them started with a capital while other did not. This caused HA to fail, after changing the hostname/dns name and a reboot everything worked fine again.

I can imagine this happens because of the fact that VirtualCenter is actually performing as a DNS/Hosts file for HA. Inconsistent naming has always been, and probably will always be a problem. So before upgrading, check your hostname and /etc/hosts file!

Previously, enabling VMware High Availability required DNS resolution of all ESX Server hosts in a High Availability cluster. This was done using configuring DNS records or by adding all of the host names and IP addresses to the /etc/hosts file on each server.
Starting with the ESX Server 3.5 Update2 release, DNS resolution or /etc/hosts file entries are no longer required to configure High Availability. The host name and IP address information will now be provided by the managing VirtualCenter Server. the source