Introduction
VMware vSphere Hypervisor is a bare metal hypervisor (a.k.a. type 1, native hypervisor) that run directly on host’s hardware. It has a management interface for users to create, manage and configure virtual machines run on top of it. VMware vSphere Hypervisor is one of the free product available to communities who like to run virtual machines natively. A common usage for Type 1 hypervisors is deploying backend services for group or cloud applications.
An alternate virtual machine deployment strategy is running type 2 (or hosted) hypervisor under an OS. Some examples includes KVM, VMWare Workstation and VirtualBox. Type 2 hypervisors is used mostly in personal task that need virtual machines for testing, debugging or carry out jobs temporary without interrupting host OS.
Competitor
A direct competitor of VMware vSphere Hypervisor is XEN hypervisor. XEN is an open source product. There are few XEN distributors. To get start with XEN, try Citrix XenServer. It doesn’t involve complicated kernel compilation and installation. It’s deployment strategy is similar to VMware vSphere Hypervisor.
After doing few performance and deployment testing for both vSphere and XEN hypervisor. I personally few that VMware vSphere Hypervisor outperform XEN in some aspects. The first area I test is the virtual network speed among these 2 hypervisors. I test a host equipped with a gigabit NIC running a FreeNAS virtual machine. I transfer a large file from CIFS share of FreeNAS. The result is vSphere transfer at double the rate of FreeNAS.
While this doesn’t mean vSphere is simply better than XEN. I was running XENServer out of the box. There may be options to compile an optimized version of my own XEN in order to maximised it’s performance that could perform as good as vSphere or better. However, It is beyond my ability at the moment. Thus, I use VMware vSphere as my first hypervisor.
Installation
Download VMware vSphere hypervisor ISO file from VMWare site. You may need to register first before download the product. Use one the following deployment methods that suits your environment after finish download.
Deploy via CD-ROM
This is the most easiest method. Burn the ISO file in CD-ROM and boot the CD on the machine. Follow instructions on screen to finish the installation.
Deploy via USB flash drive
If you want to save the world by not wasting a CD-ROM, you may create a bootable USB flash drive from the ISO by using tools like UNetbootin. After burn the ISO into flash drive, follow the steps to create a Kickstart script or else the installation will fail in the middle.
Change file isolinux.cfg
Open isolinux.cfg in USB flash drive and add “ks=usb” as follow:
default menu.c32
menu title VMware VMvisor Boot Menu
timeout 80
label ESXi Installer
menu label ^ESXi Installer
kernel mboot.c32
append vmkboot.gz ks=usb --- vmkernel.gz --- sys.vgz --- cim.vgz --- ienviron.vgz --- install.vgz
label ^Boot from local disk
menu label ^Boot from local disk
localboot 0x80
Create a new file ks.cfg
vmaccepteula
serialnum --esx=<Serial number from VMwre>
rootpw password
autopart --firstdisk --overwritevmfs
network --bootproto=dhcp
install usb
reboot
Click here (http://www.vmware.com/pdf/vsphere4/r41/vsp_41_esxi_i_vc_setup_guide.pdf) for more information about KickStart script.
You may now boot your machine with USB boot enable in BIOS and start installation. Please note that KickStart installation may erase your hard drive content without any warning prompt. Use it with care.
Deploy via PXE
This is my favourite deployment strategy as all task is done via network. You should have your PXE solution ready in your environment.
Follow the steps to prepare for PXE installation:
- Mount the vSphere hypervisor installation ISO file
- Copy all files and folders from ISO mount to TFTPBOOT folder. e.g.: /var/lib/tftpboot/vsphere.410/
- You may share the above folder in NFS, HTTP or FTP to use in later stage.
- Create a PXE entry in pxe configuration file:
label VMware vSphere Hypervisor
menu label VMware vSphere Hypervisor 4.1.0.update1-348481.x86_64
kernel vsphere.410/mboot.c32
append vsphere.410/vmkboot.gz ks=nfs://192.168.0.2/var/lib/tftpboot/ks.cfg --- vsphere.410/vmkernel.gz --- vsphere.410/sys.vgz --- vsphere.410/cim.vgz --- vsphere.410/ienviron.vgz --- vsphere.410/install.vgz
- The above setting use nfs to export a kickstart file ks.cfg. You may use HTTP or FTP to export the file too. Just find a suitable place for your KickStart file.
- Create a KickStart file ks.cfg:
vmaccepteula
serialnum --esx=<Serial number from VMwre>
rootpw password
autopart --firstdisk --overwritevmfs
network --bootproto=dhcp
install nfs --server=192.168.0.2 --dir=/var/lib/tftpboot/vsphere.410
reboot
- You may use PXE boot to start the installation now.
- Please note that KickStart script is always required or else the installation will fail in the middle. Again remember that KickStart installation may erase your hard drive content without any warning prompt. Use it with care.
Configuration
Once the VMware vSphere hypervisor is up and running. The configuration is easy.
Identify the IP address of your hypervisor and use browser to navigate to the http://<hypervisor-ip>/. Download the Windows GUI client utility, install and start using the hypervisor.
Access vSphere hypervisor via SSH tunneling
Add forwarded port 443 and 902 to your favorite SSH client. For example, putty SSH tunnels configuration:
You may then connect to your vSphere hypervisor via localhost.
The vSphere GUI client may only access to port 443, 902 and 903. It won’t work with classic gateway port forwarding that alter the port number for client.
There is a problem with this design. You cannot manage more than one hypervisor via SSH tunnels at the same time as the port number may conflict with each other. A workaround solution is create a Windows machine in the same network of your hypervisors. Install the vSphere GUI client. Allow access the windows machine using Remote Desktop (RDP, port 3389) from remote.
Troubleshooting
Error – The Microsoft Visual J#2.0 Second Editor installer returned error code ‘4113’
You may encounter error
The Microsoft Visual J#2.0 Second Editor installer returned error code ‘4113’
when installing VMware vSphere Client 4.1. A possible cause is you may already have a copy of Microsoft J#2.0 x86 in your system. To overcome the problem, uninstall Microsoft Visual J#2.0 from control panel, re-run the VMware vSphere Client 4.1 installer again. The installer should download an updated version of Microsoft Visual J#2.0.
How to rename a .vmdk file
A vmdk file is a virtual machine disk file. If you have created a new HDD for a virtual machine, a new .vmdk file is crated too. vSphere doesn’t allow user to specify file name. The file name is automatically allocated. In common practices, we may create a new HDD device to store data purely. We may even move the HDD to another virtual machine from time to time. In most situations, a meaningful name is always needed to identify such HDD .vmdk file.
A solution is using console command to rename .vmdk file. First, enable SSH from hypervisor host. Identify .vmdk file start from folder /vmfs/volumes and use the following command to rename:
# vmfstools –E <old-name>.vmdk <new-name>.vmdk
Please note that a .vmdk HDD device consist of 2 files: <file-name>.vmdk and <file-name>-flat.vmdk
Ignore the “-flat” file and using vmfstools command to perform the rename. Both files will be renamed accordingly.
