Malaysia VMware Communities » ESX

PSOD on HP Proliant G7 with AMD 6100 Series

craig — Tue, 01 Mar 2011 15:52:36 +0000

There is known issues been faced by small group of user who had deployed their VMware ESX host on the latest platform with G7. You can refer to the official link from HP here and additional KB from VMWare referring to the same issues. If you are facing this, you may be the unlucky 1, but nothing much you could do as the PSOD message will refer to the CPU error, compatible issues and etc.

The only thing you could do is to wait until both HP and VMware to come out a final fix in this case. Quick solution, is change hardware vendor or different platform. I had experienced 3 times about it, in the past 2 months and this is the latest finding we had received from both VMware and HP regards the latest PSOD we had. HP had recommended to upgrade the BIOS, Firmware and driver for multiple times, but this doesn’t fix the issue we are facing. Lately there had release another new update bios and hope this problem will be gone after this.

Feel free to share any work around solution beside the official link provided by tech support.

Network Card Driver failed ESX host with DL 585 G7

craig — Tue, 18 Jan 2011 15:27:02 +0000

Recently there are couple of issues I had faced on the latest DL 585 G7 server which installed with ESX 4.0 Update 2. The common problem reported by couple of users are same which could potentially caused all the network traffic dead off for the entire ESX host. The even worst case could be happen and cause Purple screen to the ESX host. The current solution is to either update the NICs driver with the latest version, but I will suggest to disable all on board NIC and replace with either Broadcom and Intel Gigabits adaptor. This will isolate unnecessary issues which I had not seen in others servers brand.

Please refer to the VMware Forum Here for the confirmation on bugs with multiple users who experience the same issues as I did.

Maximize CPU utilization on ESX host with Cisco UCS B250M2

craig — Fri, 15 Oct 2010 16:01:50 +0000

We were doing some stress test with more than 15 VMs on a single B250M2 Cisco UCS blade machine with 2 x Intel 6 Cores 2.93Ghz, and 192GB memory. While are stress test are pretty simple, each VM been provisioned with 2 vCpu and 4GB of physical memory. We maximize the CPU load of all the virtual machine and end up I was able to capture the print screen as attach here.

Weird Thing had happened here as we maximize the CPU utilization, but the total MHZ on the ESX host had exceeded the calculation if we base on 12 x 2.93 Ghz. I am still trying to understand in details how the system can stretch more than the available capacity on the total Ghz it suppose to have with the chip set on the machine. If you do have any valuable comment to explain this, feel free to comment here as I am interesting to learn this out.

Great Post about NUMA Hyperthreading in ESX 4.1

craig — Thu, 07 Oct 2010 16:49:14 +0000

As you may aware, significant improvement had been done on the latest hypervisor from VMware vSphere 4.1.
1 of the key changes are the vCPU for each virtual machine with latest NUMA hyperthreading architecture.

I found a very details and great post talk about this topic, please read the full post from here.

This will significant improve the Consolidation ratio and performance over the virtual machine VS the previous version ESX 4.0.

How to make APC PCNS 2.2.4 work with ESXi 4.1

jlchannel — Wed, 06 Oct 2010 16:30:24 +0000

For the past 1 week, I have been busy with the APC PCNS and ESXi 4.1 and I would like to share my experience “How to make APC PCNS 2.2.4 work with ESXi 4.1″ here.

Basically I will not discuss How To Install PowerChute Network Shutdown on VMware ESX /ESXi again and you may refer to APC official link here.

If you’re try to install APC PCNS 2.2.4 on vSphere Management Assistant (vMA) 4.1 and I’m sure you will get the similar error like “This version of PowerChute Network Shutdown only support VMware ESXi” which I think APC teams should it much more clear. The error message caused by APC PCNS (ver 2.2.4) setup file – “install.sh” which check on “/etc/vima-release” file. In the vMA 4.1 released, you’re can only found “/etc/vma-release” file which changed recently. Create a symbolic link or edit the installation script can temporary ignore these error message. See this link.

Unfortunately, the solution as above does not help much. I found another serious problem which the connectivity between the ESXi 4.1, vMA 4.1 and PCNS 2.2.4 authentication problem due to “/opt/APC/PowerChute/group1/bin/shutdownhost.pl” and “vi-fastpass”.

To cut the story short, I would suggest you go with vMA 4.0 and just ignore vMA 4.1 until APC solve the problem. Again, you may consider William Lam post “Why you should upgrade from vMA 4.0 to vMA 4.1”

Process to disconnect ESX host from vCenter with DVSwitch

craig — Wed, 08 Sep 2010 13:31:59 +0000

It been quite some times I did not migrate the ESX host from 1 vCenter to another. For most of the deployment recently, we were either deploy our vSphere 4 with DVswitch or Nexus 1000V from Cisco. Here are some steps you may want to consider when you migrate the ESX host from 1 vCenter to another if you are using DVswitch. Usually we can disconnect the ESX host from vCenter and remove it from inventory, and reconnect to the new vCenter. If you are follow this way for standard vSwitch, it shouldn’t cause you any problem, but if you deploy this way for the environment which using DVswitch, the new vCenter will give you error which shown the previous DVswitch record are still tie to the ESX host on a different vCenter. Do not get panic as the Network connectivity are still working as usual, but you will not able to connect the ESX host to the new DVSwitch.

The proper way of doing this, you should consider to provision at least 1 physical connection back to the standard vswitch, and migrate all the management port and vmkernel port back to it from the existing DVSwitch. After that, you should disconnect the ESX host from the previous DVSwitch. Now you can remove the ESX host from the previous vCenter, and reconnect it to the new vCenter which you would like to migrate to. From here on wards, you should able to connect the ESX host to the new DVswitch you would like to after the ESX host presented to the new vCenter. Have fun!!!!

Storage vMotion with VAAI on EMC

craig — Sun, 15 Aug 2010 17:30:57 +0000

In 1 of the demo video, I had seen the storage vMotion performance significant improve as much as 25% of the time and reduce the storage processor overhead at roughly 20% which offload the ESX performance during the storage vMotion execution. Previously, you may aware that the storage vMotion will usually take a long time and consume a lot of resource from Host & Storage. With vStorage API Array Integration, you will able to offload this to the storage array to handle directly which reduce the system overhead from ESX host itself.

Here is the option to turn on or off the VAAI, Value of Zero meant off, and 1 refer to ON.

CMD/s spike up to very high without VAAI while executing storage vMotion.

With VAAI, it reduce the CMD/s to < 100 per second

Performance chart been captured from vCenter for Storage vMotion with and without VAAI. Huge different shown.

In general, VAAI help to offload the workload require during storage vmotion back to the array directly and help to save more resource on the ESX host.

VMware VMFS Versioning

jlchannel — Wed, 04 Aug 2010 07:58:50 +0000

VMware VMFS (Virtual Machine File System) is VMware, Inc.’s cluster file system designed for VMware Infrastructure or VMware vSphere. Basically VMFS used to store virtual machine disk images, including snapshots.

According to Wikipedia,

VMFS version 1 was used by ESX Server v1.x, which is no longer sold. It didn’t feature the cluster filesystem properties and was used only by a single server at a time. VMFS1 is a flat filesystem with no directory structure. — Officially named “VMware File System”
VMFS version 2 is used by ESX Server v2.x and (in a limited capacity) v3.x. VMFS2 is a flat filesystem with no directory structure. — Officially named “VMware File System”
VMFS version 3 is used by ESX Server v3.x and vSphere (4.x). As a most noticeable feature, it introduced directory structure in the filesystem. Older versions of ESX Server cannot read or write VMFS3 volumes. Beginning from ESX 3 and VMFS3, virtual machine configuration files are stored in the VMFS partition by default. — Officially named “VMware Virtual Machine File System”

In order to know the exact VMFS version number, see below:

VMware ESX 3 – VMFS ver 3.21
VMware ESX 3.5 – VMFS ver 3.31
VMware vSphere 4 – VMFS ver 3.33
VMware vSphere 4.1 – VMFS ver 3.46

Please take note that migration between different VMFS version may cause some problem in the sense of vSphere vStorage features, probably you may read more here or refer to vSphere Upgrade Guide.

Windows 2008 R2 officially supported on vCenter 4.1

craig — Wed, 14 Jul 2010 12:52:15 +0000

With the VMware vSphere 4.1 release, VMware had officially supported the Windows 2008 R2 with the latest release of the official document. It had taken such a long period for VMWare to officially announce in the compatibility matrix documentation.

Please find the full information from here.

Surprise Finding on ESX Host after SAN switch outage

craig — Thu, 01 Jul 2010 15:14:28 +0000

I was busy setup the demo solution for the Cisco summit yesterday. The Demo we had were displaying the VMware, Cisco UCS, Nexus 5000, MDS 9124 & Netapp Storage Solution. 1 of the Surprise thing happened during the setup, which the power source for our MDS 9124 had been tripped during the installation yesterday. In this scenerio, all our connection to ESX host and VM were disconnected. It took us for 25 mins to recovered the power failure and the MDS Switch was back on line after that. I was thought to reboot all the ESX host as we are performing BOOT FROM SAN for all the ESX hosts that we setup. Surprise happened here, which I found all the ESX host were still continue running. I did the command uptime and check the system uptime from vcenter, it showed that the ESX host were not rebooted during the SAN connection drop from UCS to our Netapp FAS storage.

I further checked the virtual machines been power on in the ESX servers, which show all the VM were continue running without system crash or rebooted. Now I realize that the failure on SAN switch may not necessary result system crash or hung, in fact it may allow you resume the system state once the SAN switch are back online, of course, this is no guarantee assumption, just some surprise finding experienced yesterday would like to share here.