After few nights of troubleshooting, I was running out of clue. Came to the sudden, I accidentally search the computer name in AD under the category of Users object group, and I found an user account been created in AD with the same name as we define on the cluster name. I was wondering whether this could caused the confuse to the system. Therefore, I was suggesting to remove the user name temporally as it was not use at the moment and tried to reform the cluster. Guess what, the cluster form up as it needed to be in less than 1 minutes. We were so happy to end the marathon troubleshooting every night well and we were also very pissed off with the bugs we face here.

I am not very sure what is the real reason behind can really cause this, but this is the real case which take us few days to figure out. I think Microsoft should seriously look into this problem as it sound stupid to have this bugs in place today. User name and computer object name are always not the same thing in AD, how can the system confuse with it?If this is unavoidable, they should put in to the documentation or check list to remind the users on this. My personal comment on Windows 2008 Cluster technology, it does not make the administrator life simple, and it added too much dependency for the Microsoft AD. Please take note that this problem happen to both windows 2008 and windows 2008 R2.

Traditional legacy or standalone environment, we often realize there are many solutions perform replication from primary data center to DR center via host base, storage base or image base replication. All of them has the pros & cons depend what is the objective of the specified DR project users are looking at. DR consistency and usability during DR scenario & practices always the biggest challenge in every IT department today.

In virtual environment, hypervisor will encapsulate the entire virtual system in to multiple files. These files are usually located on the Shared storage environment & replicated across to DR center via storage replication. Of course, this solution are come with a cost, may not apply to every environment. Well, my intention is to compare the simplicity of DR in virtual compare to physical environment. Since everything are on SAN or NAS in virtual environment, everything could had just taken care by the storage and replicated over to DR center. With VMware Site Recovery Manager solution, extra management capability had built in allow users to predefine the DR policy to ensure VMs are ready to production in DR scenario. The entire state of the virtual machine include operating system, application data, and databases are fully replicated across to DR center in this case.

In physical environment, we always had challenges to maintain consistency on the operating system & application, which may not running on SAN, unless all systems are on SAN boot environment without local hard drive. Due to complexity and cost concerns, not many of the enterprise IT today will have SAN boot environment. For anything is not on SAN, may require 3rd party solution or customize solutions to ensure consistency over the DR.

A re-design or DR solution due to virtualization adoption, may bring more benefits to the IT and business unit by reducing the complexity compare to the physical environment.

You may have 30 to 50 VMs into single host today due to high density server with more CPU core or more memory per single system. In the next second, you may face the hardware failure on 1 of the host, there will be around 50 VMs down at 1 time and require another 20 mins before all the virtual machine could be successful restarted on the surviving host. Some of them may consider this is high impact, therefore you decide to restrict the number of virtual machine in single host around 10 to 20 VM per ESX. What happen next, the TCO is high, and ROI is not efficient.  Is a tough point for most administrators to choose in this scenario. I will urge you to backward a little bit and look at the scenerio again. Before Virtualization, all the business system that only invested with standalone server without physical clustering, they do not entitle any HA as the aware off. If they want a HA in physical system, they will had to invest extra CAPEX and OPEX to maintain a same set of hardware and operating system, just for failover purpose. Again, even the operating system clustering does not provide 100% uptime.

When they adopted to Virtualization today, they do know how the HA will work, as I even personally demo to the business and explain how the HA work in ESX servers. Well, they pay less to the system cost VS Standalone servers but gain. They are happy and acceptable with the 20 mins recovery time if the host are failed due to the hardware failure on the ESX server.  Well, if 20 mins are not acceptable for them today, what about the users who even refuse to host their system in the virtual infrastructure today? There are still many of the systems are currently running on the standalone host without physical clustering. VMware had done the great job by providing ESX cluster and Virtual machine heartbeat monitoring. Users will not get this if they are still on standalone host today.

If you would like to minimize the system down time due to ESX host failure, you can always build the Microsoft cluster or Linux cluster on top of the virtual machines. Of course, this will require extra efforts to manage and maintain just like 2 physical system.  Another choice you may think of, is the Fault Tolerance function from VMware. Of course, you should always configure the policies to control the DRS activities to ensure all your same functionalities system are always split to multiple ESX hosts in the same cluster.

From my experience on deploying multi tier application system in x86 platform, I will say the application design are much critical to improve the uptime from time to time. Those intelligent application today, are able to scale dynamically from multi-tier perspective with auto failover and load balance mode enable. In the event of any application server are down, the users will be auto redirect to the available application server automatically. Well, even we had planned everything in place, there are still much more thing to be involved to prevent the single point of failure such as, SAN storage and Networking.

My opinion on high consolidation ratio in virtualization today, does not mean the risks are increasing. It is well depend on the architecture planning, consideration, design and implementation by the team.

Please make sure you have selected Other 2.6x Linux 32bit as per your guest OS.

Download Chrome OS VMware Image at http://gdgt.com/google/chrome-os/download/

I would like to share how to configure memory “hot add” for Windows 2003 virtual machine.

Please make sure the virtual machine is power off before proceed and this is one time setup.

• Right click on virtual machine
• Click Edit Settings
• Click Options
• Select “Enable memory hot add for this virtual machine” under Memory/CPU Hotplug.
• Click OK

Testing time! Power on your virtual machine and increase your memory size on the fly now.

Note: You can increase the memory on the fly but NOT decrease the memory during virtual machine is power on.

Enjoy!

Option 1:
# grep buildNr /usr/bin/vmware-config-tools.pl
my $buildNr;
$buildNr = '3.5.0 build-143128';
return remove_whitespaces($buildNr);

Option 2:
# vmware-config-tools.pl -h
VMware Tools 3.5.0 build-143128 for Linux

Option 3:
# rpm -qa|grep VM
VMwareTools-7302-143128
Note: Only apply to RPM installed

Enjoy and I hope this is useful!

According to VMware KB Article 51306

VMware has identified a problem with RHEL5, RHEL4 U4, RHEL4 U3, SLES10, and SLES9 SP3 guest operating systems. Their file systems may become read-only in the event of busy I/O retry or path failover of the ESX Server’s SAN or iSCSI storage.

This issue may affect other Linux distributions based on early 2.6 kernels as well, such as Ubuntu 7.04

The same behavior is expected even on a native Linux environment, where the time required for the file system to become read-only depends on the number of paths available to a particular target, the multi-path software installed on the operating system, and whether the failing I/O was to an EXT3 Journal. However, the problem is aggravated in an ESX Server environment because ESX Server manages multiple paths to the storage target and provides a single path to the guest operating system, which effectively reduces the number of retries done by the guest operating system.

And the solution is:

This is not an ESX Server bug. This Linux kernel bug has been fixed as of version 2.6.22.

Note: This article does not supersede the Guest Operating System Installation Guide, a guest operating system upgrade may require an ESX Server upgrade as well.

For RHEL5, the resolution is to upgrade to Update 1, also refereed to as RHEL5.1

For RHEL4 U3 and RHEL U4, the resolution is to upgrade to Update 5, also refereed to as RHEL 4.5.

For SLES10, the resolution is to upgrade to SP2. For more information, see Novell KB TID 3605538.

For SLES9 SP3, the resolution is to upgrade to SP4, or SP3 Maintenance Release build 2.6.5-7.286.
For more information, see TID 3584352 – Filesystem goes read-only in VMware

For Ubuntu 7.04, the resolution is to upgrade to 7.10

Beside that,  I would also suggest you check Novell Support @

• Ext3 filesystem goes read-only without the underlying storage reporting errors
• Filesystem goes read-only in VMware

Hope you won’t need to go through unnecessary step. Enjoy!

Preliminary Note

• Operating System: Windows 2003
• Hostname: Win07
• Initial drive c: hard disk space: 12 GB
• Allocate additional hard disk space: 8GB
• Total size(resize) = 20GB
• VMware ESX version 3.5 update 3
• GPart LiveCD 0.3.9-4

Note: We’re NOT warranty and response for any disk corruption. Please make sure you have BACKUP before proceed.

Here you go step by step:

1. Power off Windows 2003 virtual machine.
2. Resize existing hard disk size from 12Gb to 20Gb.



3. Power on Windows 2003 virtual machine and make sure you can see additional disk allocated.



4. Once again, restart Windows 2003 virtual machine and boot with GPart LiveCD(default settings).



5. Select ‘Don’t touch keymap’ and press ‘ENTER’.
6. Press ’33′ and ‘ENTER’.
7. Please ‘ENTER’ to continue.
8. Right click on GParted menu -> click ‘Resize/Move’.
9. Use your mouse and scroll/resize /dev/sda1 to maximum size.



10. Click ‘Resize/Move’.
11. Click ‘Apply’ twice.
12. Click ‘Close’.



13. Restart Windows 2003 virtual machine again and I would suggest you run Windows checkdisk(chkdsk) during boot up.



14. Go to Windows Disk Management tools.



15. Gongratulation if you can see 20Gb drive C: available.

Any feedback or comment are welcome and I hope this guide is helpful.

The only difficulty I have now is Daemon Tools, which use for ISO purpose. Beside that, I am using it as my day to day operational purpose including Microsoft Office, firefox, IE 8, Live messenger and etc. Respond wise had been significant improve as compare to Vista previously.

I am not installed my Workstation to Windows 7 64 bits Ultimate version and use in full mode for my office work. I would like to say I am happy on it. If you want to have a try on this, you will always able to install the windows 7 on both VMware Workstation and VMware Server. Have fun.

How about you?
Get gOS and Fedora 10 now!