VMware Partner Exchange Technical Notes

Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)

Below are some notes that I took from the VMware Partner Exchange technical sessions that I attended.  I left off the BCDR Workshop because it will become a separate post.

Upgrade and Migration Tips:
This session was conducted by Mustafa Kahlil, who is probably THE senior SE at VMware. He has over 10 years with the company and started around ESX 0.9. The session centered around a group of flow charts that followed a nice decision tree for upgrade or migration to VI4. The flowchart will provide everything you need for a upgrade / migration engagement. Some highlights: “Upgrade VMotion” will perform a combination VMotion from ESX 2.5 to ESX/ESXi 4 and a Storage VMotion from VMFS 2.x to VMFS 3.x. A VMotion licence will be required. This will allow direct MIGRATION from ESX 2.5 to ESX/ESXi 4. In order to UPGRADE, the latest update build of ESX/ESXi 3.5 will be required. A “vSphere Update Utility” (AKA VMware Infrastructure Update Utility) will be used to update ESXi if VUM is not used. VUM will be the easiest path. The utility will only be able to update one host at a time, but could be scripted to perform a chain of updates. THERE WILL BE NO UPGRADE PATH FOR VMs ON NFS! Only migration will be used for NFS VMs. The most interesting thing Mustafa said was

“Eventually, no service console”

Remember this in your Plan and Design engagements for VI3. I have always been a supporter of ESXi over ESX.

Performance Best Practices for ESX:
This was, by far, THE BEST session. It was two hours of drinking from a fire hose. I took three pages of notes and they didn’t get through all of the slides. Next week, they are expecting to release an updated performance whitepaper on the VROOM! site. Here are the main things that should be considered for performance:

First and foremost, VM performance has little to do with the ESX configuration tweaks, but has a LOT to do with VM configuration tweaks. The main points were this – Understand the application profile, choose the platform wisely and tune the VM settings. All of the performance information below assumes enough CPU and RAM are provided to an app.

Most CPU intensive apps virtualize very well. Most memory intensive apps virtualize very well. As stated before VMware demonstrated a RHEL/ORA VM that could handle 8x of Visa’s online transactions.

Network usage – between 1 and 16 Gbps will virtualize with proper VM tuning, Over 16Gbps will not. (40Gbps in VI4)
Storage I/O – between 10-100k will virtualize with proper VM tuning. Over 100k will not (200k in VI4)
Anything with more than 8CPUs or 255GB RAM will also not virtualize.

See the doc -> http://www.vmware.com/pdf/asplos235_adams.pdf

Use Intel VT / AMD RVI. The newer chips also include hardware based paging for memory, which takes a load off of the hypervisor.

Use TSO and Jumbo Frames for networks. JF is disabled by default and must be enabled on all devices involved – NIC BIOS, vSwitch, VM OS, pSwitch. VI4 will support JF in iSCSI as well. pNICs should also handle 64bit DMA and multiple scatter/gather elements for the frame. Also, force speed and duplex, separate traffic, use teamin, etc.

Configure storage properly – spindle count, hot spots, LUN layout, etc. Use VMFS instead of RDMs. Use 4k I/O for best performance over 16k and 64k.

VM setting:
Choose the proper OS. This determines the proper monitor type, optimal devices, etc.
Use 64bit OSes for high memory usage
Enable large pages in OS and app (default is disabled)
most apps do not scale well beyond 4/8 CPUs with the exception of RHEL/ORA

See the doc http://www.vmware.com/files/pdf/consolidating_webapps_vi3_wp.pdf


They should not need to be tweaked! Kernel latency MAY indicate it is necessary to tweak queues.

Perform adminitsrative tasks (new VMs, clones, etc.) during off hours. These produce storage performance hits.

Leave a Reply