ESX 4.1 USB install and Password complexity changes

As a point release i’m not sure why VMware decided to completely change the layout of files on the CD ISO along with change various system files, however they have. I suppose one change is beneficial as it improves the method for creating a USB stick which for previous versions of ESXi is documented here. They have also changed console access and ssh access to the hypervisor, which now can be enabled from the orange console screen under TSM (technical support mode) settings.

Writing to a USB stick:

Now the iso contains a simple file called imagedd.bz2 that is found in the root of the iso, which just need bunzip to decompress it and the dd’ing to a USB stick as documented before.

Password complexity:

At the moment there is nothing about this on the internet so it was a case of going through a few files to find it, but previously /etc/pam.d/common-password contained all of the password complexity requirements as documented on the VMware KB. However now all of the password requirements are located in the file /etc/pam.d/system-auth, so this file will need editing if you don’t want insane password requirements for all users.


As previously mentioned i’ve always been a XEN advocate for the hypervisor sitting on the physical machine, given the ready availability of a paravirtualised kernel for my Linux VMs. However a requirement to get to grips with VMware has led me to deploy ESXi on my systems so that I can have a proper look around at the OS and how it manages virtual machines. I’ve got disks all over the place, however my server I use for all my testing has a set up (and has reached capacity) meaning that i can’t use those disks. I found an old IDE disk that I installed in there, however the fiddling around with the oem.tgz(explained another time) never seemed to work for me at this point. So I picked up a USB key for ‚ā¨8 and decided to do a USB boot with the hypervisor on there.

This is pretty straightforward task to do and can be accomplished in two methods of either botching the install halfway through or pulling the image from the install CD and doing a raw write to the USB device. I opted for pulling the image from the CD and dd’ing this image onto my USB key by doing the following methods:

1. Acquire VMware ESXi 4.0 from vmware

2. Mount the CD (in linux by mount -o loop <path to ISO> <mount point>, or double clicking in OSX ūüėČ )

3. Copy install.tgz from the CD and extract in a working location, which should eventually give you a directory structure.

4. bunzip /usr/lib/Vmware/install/VMware-VMvisor-big-164009-x86_64.dd.bz2 (or equivalent file)

5. dd if=<path to .dd file> of=<path to USB device>

6. Change BIOS settings to boot from USB and boot up.

7. Set IP address, download VSphere client and off you go.

Refer to for any issues

VMware ESXi 3.5 /4.0 on Xen (How-to)

This may seem a truly useless idea to a lot of people, however I’ve always found having a ‘lab’ at home capable of building pretty much every system scenario very useful. Dealing daily with VMware ESX servers and VMs in a production environment means that I can never “fiddle” around and get to grips with whats under the hood or deal with the unsupported or hidden functionality. My Xen server has allowed me to create pretty much every scenario I may need Oracle RAC clusters, interoperability¬†between various operating systems and various development environments. When I first received the server that I use for my environments my first choice of setup was going to be a VMware ESX setup, however the hardware requirements restrict most installations to a subset of hardware configurations meaning I couldn’t install it. Originally it would have been impossible to install it under a xen HVM on the basis that the virtualised network adapters are unsupported by ESX, however luckily from 3.4.0 onwards the xen-tools have been updated and allow the use of the e1000/e100 network.

HOW-TO: Sun Cluster in VMware Fusion

VMWare fusion cluster…

For all those people that need a sun cluster on their macbook. This is a small how-to of sorts, I’ll not go into full detail regarding everything as if you can’t manage the simpler steps then I find it unlikely you’ll manage to handle the later tasks of configuring sun cluster.

Removing a Persistent Bridge in xen after reboots

The most common method for networking using xen is to use a network bridge with your physical ethernet and then the virtual nics associated with xen domains. The default install and configuration will result in a default xen bridge (xenbr0) which will have your ethernet and virtual nics in. This information has to be explicitly declared in the various xen configuration files, however xen will take care of the actual plumbing and configuring of the bridge and the interfaces. 

However, xen has an¬†oddity¬†(in my opinion) it appears that xend will monitor the bridges on your dom0 and add any other bridges to it’s state. Which means should you manually create a bridge e.g.¬†

spike ~ # brctl addbr testbr0

xend will see that this bridge has been created and add it to it’s state configuration. On a reboot or restart of xend, what will happen is that xend will configure the networking back to the state that it recorded. This means that not only will xenbr0 be created so will testbr0, which wouldn’t be a problem if your virtual nics were added to the correct bridge (xenbr0). However they more than likely be added to testbr0 meaning that your domU’s will have no networking, unless you manually move the virtual nic to the correct bridge.¬†

To permanently remove bridges you need to stop xend (/etc/init.d/xend stop *BEWARE* this will stop all domUs) then go to /var/lib/xend/state/ and edit the network.xml. The entire network uuid section containing the bridge you want removing will need deleting, ensure you back everything up before hand. 

Starting xend now will result in only the correct bridges being created and the domUs nics will be added to the correct bridge.