I decide to do a final round of import which keep every single configuration as default. All the configuration of the existing VM had not been changed and it works. After the success import, I had to manually update the vmtools and virtual hardware version. I had also cloned the virtual machine to the new VM name that I wanted to, with thin provision enable. It had been taken 6 hours for the entire import process, which is consider long as the virtual machine image was 400GB. I will suggest to leave the default setting for future import process as it shown as more consistent process. The rest of the configuration always can be done right after the success import.

I am able to get the ESX 3.5 to be manage by the latest vcenter. A vmotion from ESX 3.5 to vsphere 4 had been successes too, but the latest version of virtual machine which built from vSphere 4 might not compatible to vmotion back to the ESX 3.5 hosts. At the same time, if you have different processors chipset in the environment and require EVC to be turned on, it may be a little challenge to do so. You may want to ensure the EVC to be done with no down time.  You may need to refer to my previous post about how to enable EVC with no down time.

This trick is workable in the case. The new cluster created in vSphere 4 environment, may temporally disable the HA and DRS due to the incompatibility within ESX 3.5 and vSphere 4 for VMotion, which may happen on the latest virtual hardware version which provided by vSphere 4. Anyway, my test will still going on to further analyze the best upgrade method to be used to our environment due to the challenge of different region, time zone and business function we currently serve with our VMware environment.

VMware highly recommend to perform upgrade to vCenter 2.5 update 4 to support the ESX 3.5 update 4. ESX 3.5 update 4 will require vmtools to be upgraded too.

For more information, please visit to the official release note from VMware.

A success installation of windows 7 on vSphere. I had able to installed the VMtools properly on the Virtual Machine.

http://malaysiavm.com/blog/?p=782 Being a 1st time Mac user I am truly impress with the performance & capability. I was a true PC users with windows & started to use Linux quite a bit for passed 2-3 years.

Recently with anonymous tips from someone I was able to get ESX running inside VMware Fusion Version 2.0.1 (128865).

Just create a VM as per normal wizard & select “Generic Linux” or “RedHat Linux” works well for me.

In order to get a guest VM power up inside ESX running on Fusion you will need the following setting inside the .vmx configuration:-

ethernet0.virtualDev = “e1000″

monitor.virtual_exec = “hardware”

monitor_control.restrict_backdoor = “true”

Once installed you can just connect with the standard VI client as per normal. ESX will detect all the BIOS & hardware config as well.

The above .vmx config will work with VMware Workstation from v6.x onwards.

As I was conducting some testing which required quite a number of VMs. I was able to have the following running in a single MacBook Pro:-

2 * 768Mb RAM Windows 2003 RC2
1 * 1.3Gb RAM ESX 3.5 U3
1 * 512Mb RAM Ubuntu 64bit
1 * 256Mb RAM Knoppix

As follow is hardware spec for my Mac

This beast is really value for $$$. I am sure I can’t run that many VMs in a M$ environment with the same hardware spec.  As why I need to have so many VMs running will continue the series next time.

Here I would like to share my experience on how I get this enable without interrupt my existing production environment. By default, the features will tell you to power off all your VM before you can enable this features. Here is the tweak around solution you may want to try. Most of the time, we run critical application on VM which able to minimize the down time for us.

To have Enhanced VMotion Compatibility(EVC) working, 1st you need to create a new cluster. This cluster is not necessary to have HA/DRS running itself, because is to really allow you to move the existing production VM to the temp servers. At the same time, you can setup 1 or 2 temporally ESX Server with the evaluation edition, which have similiar configuration with your production ESX. This is to allow Vmotion happen between the ESX host.

Once you had those ready, start to VMotion all the VM out from the production ESX to the Newly build temporally ESX, until your existing production ESX cluster is empty with any of the VM power on and running.

Your cluster is now ready to configure for EVC. Right click your cluster and choose Edit Setting, and click on the VMware EVC. Select the option Enable EVC for Intel or AMD ( This will depend which processor you are using in your environment). Click Ok after that and the cluster will enable the EVC for you.

Once finish, you have EVC ready for your environment and say goodbye for processor incompatible on the Vmotion. Now you can vmotion back all the VM into this HA/DRS production cluster, and decommission your temp ESX servers you just built.

Please note that the 2 temporally ESX servers are not compatible for Vmotion before the EVC enable.

Each of the patches had it’s own KB to describe the patches details. I am currently patch up my test machine by using the Update Manager in my Virtual Center. If you plan to do the same, please ensure you update manager had the latest inventory updated from the Internet.

ESX Patches Download

Installation – ESX 3.5i had advantages as the entire process is fast and simple. ESX 3.5 require more interaction as it looks similiar to Linux installation. I know the ESX 3.5 can be script and customize by using the ks.cfg which I had done previously for mass deployment. For comparison 1 to 1, ESX 3.5i is much more easier and faster.

Configuration – Basically I dun really find much different as I do manage this machine with my virtual center. The only different is the Linux connection and command no longer usable on ESX 3.5i. By the way, I read some artical to tweak around to make the SSH work on the 3.5i, but I will prefer to proceed with powershell or CLI if I do need to use command prompt.

Perfomance – ESX 3.5i had better through put. In my test, I created 3 VM which 2 of them running on Windows 2003 SP2 with 4GB memory and 4Vcpu, plus additional 1 VM with SUSE Linux. I did the same on ESX 3.5 too. The respond on the ESX 3.5i is much smooth and not lacking, as ESX 3.5 you will see some lacking from the console open on Virtual center.  Follow by file copy test, the VM on ESX 3.5i is slightly faster than ESX 3.5. just less than a minute faster which I tried to copy some file with 20GB. Beside these points, I had not found anything different.

Manage ability – ESX 3.5 will still be the best, as there are none of the software vendor will guarantee bugless on their products. If the ESX 3.5 having some technical issue, it can be easily troubleshoot and anlayze from the Linux command which is more familiar with. ESX 3.5i still have a gap to be close up as is still new to most users yet.

Here is all my finding and I will post more in the future for any new finding