Malaysia VMware Communities » ESX

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.

Tags: EMC, ESX, Storage Vmotion, VAAI, VMware

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.

Tags: ESX, version, VMFS, VMware, vSphere

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.

Tags: ESX, VMware, vSphere 4.1, windows 2008 R2

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.

Tags: Cisco UCS, ESX, MDS, Netapp, Nexus 5000, SAN, VMware

VMware vCenter 4.0 Update 2 & VMware vSPhere 4.0 Update 2 Released

jlchannel — Fri, 11 Jun 2010 04:22:30 +0000

VMware have been released VMware vCenter 4.0 Update 2 & VMware vSphere 4.0 Update 2 on 10 June 2010.

Latest version:
vCenter Server 4.0 Update 2 (Build 258672)
vSphere Client 4.0 Update 2 (Build 258672)
ESX 4.0 Update 2 (Build 261974)
VMware Tools (Build 261974)

What ‘s new about VMware vCenter 4.0 Update 2:

Guest Operating System Customization Improvements: vCenter Server now supports customization of the following guest operating systems:
- Windows XP Professional SP2 (x64) serviced by Windows Server 2003 SP2
- SLES 11 (x32 and x64)
- SLES 10 SP3 (x32 and x64)
- RHEL 5.5 Server Platform (x32 and x64)
- RHEL 5.4 Server Platform (x32 and x64)
- RHEL 4.8 Server Platform (x32 and 64)
- Debian 5.0 (x32 and x64)
- Debian 5.0 R1 (x32 and x64)
- Debian 5.0 R2 (x32 and x64)
Resolved Issues:In addition, this release delivers a number of bug fixes that have been documented in theResolved Issues section.

What ‘s new about VMware vSPhere 4.0 Update 2:

Enablement of Fault Tolerance Functionality for Intel Xeon 56xx Series processors— vSphere 4.0 Update 1 supports the Intel Xeon 56xx Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel Xeon 56xx Series processors.
Enablement of Fault Tolerance Functionality for Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors— vSphere 4.0 Update 1 supports the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors without Fault Tolerance. vSphere 4.0 Update 2 enables Fault Tolerance functionality for the Intel i3/i5 Clarkdale Series and Intel Xeon 34xx Clarkdale Series processors.
Enablement of IOMMU Functionality for AMD Opteron 61xx and 41xx Series processors— vSphere 4.0 Update 1 supports the AMD Opteron 61xx and 41xx Series processors without input/output memory management unit (IOMMU). vSphere 4.0 Update 2 enables IOMMU functionality for the AMD Opteron 61xx and 41xx Series processors.
Enhancement of the esxtop/resxtop utility— vSphere 4.0 Update 2 includes an enhancement of the performance monitoring utilities, esxtop and resxtop. The esxtop/resxtop utilities now provide visibility into the performance of NFS datastores in that they display the following statistics for NFS datastores: Reads/s, writes/s, MBreads/s,MBwrtn/s, cmds/s, GAVG/s(guest latency).
Additional Guest Operating System Support— ESX/ESXi 4.0 Update 2 adds support for Ubuntu 10.04. For a complete list of supported guest operating systems with this release, see the VMware Compatibility Guide.

Check out VMware vCenter 4 Update 2 Release Notes here and VMware vSphere Update 2 Release Notes here.

In order to upgrade or download, please refer to VMware download page here.

Tags: download, ESX, notes, Patch, release, update, vCenter, VMware, vSphere

‘False’ Alarm Host connection failure

jlchannel — Fri, 28 May 2010 06:11:13 +0000

For the past few weeks, my customers keep received an alarm “Host connection failure” email alerts via VMware vCenter but end up it’s a false alarm.

The email alert example as below:
Target: kulsrvprd01.malaysiavm.com
Stateless event alarm

Alarm Definition:
([Event alarm expression: Cannot connect host - incorrect Ccagent] OR [Event alarm expression: Cannot connect host - network error] OR [Event alarm expression: Cannot connect host - time-out] OR [Event alarm expression: Cannot connect host - time-out] OR [Event alarm expression: Host connection lost])

Event details:
Host kulsrvprd01.malaysiavm.com in DC1 is not responding

VMware Technical support team was told us this is a known bug in current release vSphere 4.0. The VMware engineering team is still working on it and the fix for this issue will be next released.

Quick Help: You can stop the alarm immediately after make any changes on the alarm definition such as changed the Alarm Action notification setting frequency from 5 minutes to 10 minutes.

Anyway, I would suggest to keep “Host connection failure” alarm enable. And let’s wait for the patches. Hope you’re aware about the problem.

Additional Tips: Learn How to configure Email Alert here.

Tags: alarm, connection, definition, ESX, host, vCenter, VMware

Virtualization Design with Gigabits VS 10G Ehternet

craig — Wed, 12 May 2010 01:23:34 +0000

Today, 10 G Ethernet consider as common technology at least to the enterprise customer. Many of us are looking into 10G Ethernet from server to switch via L2 or L3 networking perspective. The main reason behind this are due to the Virtualization and Cloud Computing technology driven. Few years ago when we came out the design with multiple gigabits NICs on the ESX host to support NIC teaming, load balancing and etc, which may end up deliver around 14 Gbps of network bandwidth and 8Gbps of FC bandwidth per host. Each ESX host are consolidate 20 to 30 virtual machines. At that time, this may be the best option we could had done due to technology limitation. Is this design GOOD enough? I will say yes for previously, and NO for today technology availability.

Photo shot of the real environment which have 14 gigabits NIC Ports and 4 x 2 Gbps FC.

If you are going to adopt virtualization technology in your environment today, you should consider the comparison within gigabits and 10G Ethernet. Of course, for some environment which may not require 10G if the number of virtual machines and IO requirement are low, and I absolutely agreed that we shouldn’t over provision what you require in the IT infrastructure. But if you are looking for medium and large scale virtualization and consolidation, I will say that 10G Ethernet are the way to go from now. 10G Ethernet provide lower latency vs traditional gigabits Ethernet. It does solve the physical and virtual management on the networking perspective on virtualization. From operational standpoint, it simplified the data center by reducing the complexity from switch or storage management.

From VMware architecture, if you are currently on gigabits environment, you may end up create multiple vswtich, multiple DVswitch, or multiple uplink for different port group and VLAN. Well, no problem of doing this of course, but when the number of interfaces increase to 18 NICs per Server, you will spend hours to just plug in and trace all the physical cable 1 by 1. An example here for reference, if you have 2 x 10G Ethernet per ESX host, the implementation will be much more simplified. a DV switch for all port group require. Of course, you will maintain the standard best practices which split out the port group to multiple interfaces as usual. Of course you can applied QoS if you wish to do so, but in most scenario, you may leave it default. Now, you have 20Gbps VS 18 Gbps, and the entire management from both physical and virtual are much more simplified. With Intel Westmere and AMD 12 cores technology, you will no longer looking at virtualize 10:1 per ESX host. I had generally see the users at least virtualizing 18 to 25 per ESX host as a minimum today. Network IO become more important now since the number of virtual machine per host are increasing.

Screen short of 2 x 10G Ethernet configuration with DVswitch.

There are also plenty of storage vendor out there supported 10G Ethernet interface for ISCSI and NFS both. Meant you can have your virtual machine network and Storage traffic both running on 10G Ethernet.

Tags: 10G Ethernet, dvswitch, ESX, Gagabits, Virtualization, VMware

Upgrade from ESX 4 to ESX 4 update 1 with update manager fail

craig — Thu, 26 Nov 2009 05:26:06 +0000

Just found the note from VMware today about the possibility of upgrade fail if you are trying to update you ESX 4 to update 1 with update manager.

When attempting to upgrade ESX 4.0 to ESX 4.0 Update 1, you may experience the following symptoms:

Update Manager (VUM) upgrade operation fails or times out at 33%.
Upon reboot, the host that was being upgraded displays a purple diagnostic screen with the following error:COS Panic: Int3 @ mp_register_ioapi

Who is affected

Customers using VMware vSphere 4 upgrading to Update 1 with 3^rd party management agents running.

Solution

To avoid this issue, prior to the update, disable all 3rd party management agents running on the ESX 4.0.0 server before applying the update.

Note: The 3rd party management agents can be enabled after the upgrade is completed.

If you have already updated the ESX host, do not reboot the ESX host. Open a support request with VMware support.

WARNING: Rebooting the host means the host has to be reinstalled because it is not recoverable after a reboot.

WARNING: If you have virtual machines running on local storage, they may not be retained if you reinstall ESX 4.0 as a result of this issue. Contact VMware Support for assistance in recovering those virtual machines.

The full KB can be found here

Tags: ESX, Update Manager, VMware

Apply VMware vSphere 4 Update 1 Patches

jlchannel — Wed, 25 Nov 2009 06:12:36 +0000

VMware ESX 4.0 Update 1(Build 208167) was released on 19 Nov 2009 and I did a patch update on 3 of my vSphere Dev Servers included of 1 ESX (build 164009) server and 2 ESXi (build 164009 & 171294) servers on Dell PE2950 today.

The Redhat Linux and Windows 2003 & 2008 Virtual Machines VMware tools upgraded successful and everything look goods after the Update 1 patched.

I would suggest you refer to VMware Communities – vSphere Upgrade and Install forum & “vSphere 4u1 – any issues” thread before apply any VMware vSphere ESX/ESXi Update 1 patches on production environment.

Read more details about VMware ESX 4.0 Update 1 Release Notes here.

Updated:
Please make sure you check VMware Knowledge Base – Upgrading ESX 4.0 to 4.0 U1 using Update Manager fails or times out and rebooting the host results in a purple diagnostic screen
A quick note: The problem with U1 is now known to be limited to HP Proliant systems and HP Insight Management agents are running.

Tags: ESX, Patch, Patches, release, update, upgrade, VMware, vSphere

ESX Cluster through WAN with Netapp Metro Cluster

craig — Tue, 17 Nov 2009 16:40:20 +0000

Recently there are some request from my client who suggested to have their production and DR site to be automated protected and fail over in the event of disaster. VMware SRM seems to be right choice for most of the time, but these clients are decided to bring it to another level of fail over procedure during the DR happen. I am doing some research today and found this interesting topic from Netapp which the Metro cluster suppose to synchronize from production to DR through dark fiber to prevent controller failure, DR or disk corruption.

If the bandwidth is not a concern in this case, ESX HA cluster through both data center is workable with Netapp metro cluster. In the event of disaster happen, the VM should be restarted as the normal HA kick in from the ESX cluster.

you can read more information from the link here.

Tags: ESX, Netapp Metrocluster, SRM, VMware