vSphere

Just before Christmas VMware has released two new technical papers. The first one goes in-depth on best practices for running Allscripts Emergency Department (ED) on VMware vSphere. The seconds one is about configuration examples and troubleshooting for VMDirectPath.

Deployment Guide: Best Practices for Running Allscripts Emergency Department (ED) on VMware vSphere

This document provides direction to those interested in running Allscripts Emergency Department (ED) on VMware vSphere™ 4. It provides basic guidance on the architecture of Allscripts Emergency Department as well as the value of utilizing the VMware platform. The results of recent testing done jointly by VMware and Allscripts are covered, where the performance and functionality of Allscripts ED on VMware virtual infrastructure are characterized. Finally, some best practices for utilizing the two product sets together in your datacenter are outlined.

Configuration Examples and Troubleshooting for VMDirectPath

VMDirectPath supports a direct device connection for virtual machines running on Intel Xeon 5500 systems, which feature an implementation of the I/O memory management unit (IOMMU) called Virtual Technology for Directed I/O (VT‐d). VMDirectPath can work on AMD platforms with I/O Virtualization Technology (AMD IOMMU), but this configuration is offered as experimental support. Some machines might not have this technology enabled in the BIOS by default. Refer to your hardware documentation to learn how to enable this technology in the BIOS.

VMware has released the "Enterprise Java Applications on VMware - Best Practices Guide". This paper discusses best practices for running Enterprise Java Applications on VMware vSphere virtual machines. The guidelines will help you to get the best from your Java applications and application servers when you run them on VMware vSphere.

http://www.vmware.com/resources/techresources/1087

This Enterprise Java Applications on VMware Best Practices Guide provides information about best practices for deploying enterprise Java applications on VMware, including key best practice considerations for architecture, performance, design and sizing, and high availability. This information is intended to help IT Architects successfully deploy and run Java environments on VMware vSphere.

Android-x86 is a project to port Android open source to the x86 platform, formerly known as "patch hosting for android x86 support". In this video I’ll show you how to create a VMware vSphere virtual machine configured with the Android-x86 boot CD.

Sorry for my rude title Scott :-) but I was just on the phone with me ex Capgemini colleague Ernst Cozijnsen and we had a long discussion about super fast storage for replicas in a View environment. In the end we settled for RAM. I immediately jumped into my lab to setup a proof of concept to see how it performs and it’s pure awesomeness, faster than fast and quicker than quick. You want to see what we discussed? Well here’s the story. In the proof of concept I’m using a Windows 2008 64 bit Enterprise server with 7 GB of RAM and the StarWind iSCSI target software. I’ve configured this iSCSI target with a RAM disk of 6 GB and created a VMFS on the iSCSI target. I’ve cloned a Windows 2003 virtual machine to the newly created VMFS hosted in RAM and did some performance checks. I was astounded.

This paper describes best practices and guidance for properly deploying VMware HA in VMware vSphere 4.1.  These include discussions on proper network and storage design, and recommendations on settings for host isolation response and admission control.

http://www.vmware.com/resources/techresources/10166

Finally, with Transparent Memory Compression, 4.1 will compress memory on the fly to increase the amount of memory that appears to be available to a given VM. The new Transparent Memory Compression is of interest in the workload cases where memory -- rather than CPU cycles -- has limitations. ESX/ESXi provides a Memory Compression cache to improve virtual machine performance when using memory over-commitment. Memory Compression is enabled by default when a host's memory becomes overcommitted; ESX/ESXi compresses virtual pages and stores them in memory.  

Since accessing compressed memory is faster than accessing memory swapped to disk, Memory Compression in ESX/ESXi allows memory over-commits without significantly hindering performance. When a virtual page needs to be swapped, ESX/ESXi first attempts to compress the page. Pages that can be compressed to 2 KB or smaller are stored in the virtual machine's compression cache, increasing the capacity of the host. The maximum size can be set for the Compression Cache and disable Memory Compression using the Advanced Settings dialog box in the vSphere Client.