Yellow Bricks

by Duncan Epping

esxi

New whitepapers

· ·

VMware just published two whitepapers. I hadn’t noticed them yet and especially the second one is a very good read!

  1. VMCI Socket Performance
    The VMCI (Virtual Machine Communication Interface) device allows fast, efficient communication between virtual machines running on the same host, without using the guest networking stack. This paper presents VM-VM performance results using VMCI Sockets and compares these results to the VM-VM performance achieved using regular TCP/IP sockets.
  2. VMware vCenter Site Recovery Manager 4.0 Performance and Best Practices for Performance
    The goal of this white paper is to provide you with Site Recovery Manager performance data and recommendations so that you can architect an efficient recovery plan that minimizes the downtime for your environment.
    This white paper addresses various dimensions on which the recovery time depends:

    • Recoveries with iSCSI, FC, and NFS storage
    • Number of virtual machines and protection groups associated with a recovery plan
    • Virtual machine to protection group relation
    • Recovery site performance in a cluster with DPM and DRS
    • Configuration of various recovery plan parameters
    • Priority assignment of virtual machines in the recovery plan
    • High latency network between protected and recovery sites

    Furthermore, best practices are suggested in applicable areas so that you can optimize the recovery time using Site Recovery Manager.

vSphere and Service Console Memory

· ·

Today I read something I have not seen anywhere else before. I have always been under the impression that the memory reserved for the Service Console was increased from 272MB to 300MB. Although the bare minimum is indeed 300MB there’s another side to this story, something I did not expect but actually does make sense. As of ESX 4.0 the allocated Service Console memory automatically scales up and down when there is enough memory available during installation. Let’s make try to make that crystal clear:

  • ESX Host – 8GB RAM -> Default allocated Service Console RAM = 300MB
  • ESX Host – 16GB RAM -> Default allocated Service Console RAM = 400MB
  • ESX Host – 32GB RAM -> Default allocated Service Console RAM = 500MB
  • ESX Host – 64GB RAM -> Default allocated Service Console RAM = 602MB
  • ESX Host – 96GB RAM -> Default allocated Service Console RAM = 661MB
  • ESX Host – 128GB RAM -> Default allocated Service Console RAM = 703MB

Lessons learned:

  1. Allocated Service Console memory is based on a formula which takes available RAM into account. (Haven’t found the exact formula yet, if I do I will of course add it to this article.)
  2. Always make your swap partition 1600MB; as an increase of RAM might automatically lead to a swap partition which is too small.

ESX(i) 4.0 -> ESX(i) 4.0 U1 update

· ·

My colleague Lee Dilworth just emailed me the following. Those who are running vSphere ESX(i) and have the Cisco Nexus1000v installed might want to read this:

If your customers are on ESXi/ESX 4.0 and want to update to U1 using the vihostupdate then first they need to read this new KB:

http://kb.vmware.com/kb/1015879

From here you will see mention of a file VEM-4.0.0-update01.zip which is not on the U1 download page. One useful addition to the KB article would be to remind customers that to obtain this VEM update you need to navigate to: http://support.vmware.com/selfsupport/download/

From here select “VEM” and “4.0.0” and search. You will then see VEM-4.0.0-update01.zip. Copy this to the same folder as your ESXi patch file (ESXi-4.0.0-update01.zip) and then run:

vihostupdate --server <server> --username <uname> --password <passwd> --bundle
ESXi-4.0.0-update01.zip,VEM-4.0.0-update01.zip --bulletin
VEM400-200911014-BG,ESXi400-200911201-UG –install

Let the install run….that’s it.

C:\Program Files\VMware\VMware vSphere CLI\bin>vihostupdate.pl --server
192.168.1.1 --bundle C:\Install\U1\ESXi-4.0.0-update01.zip,
C:\Install\U1\VEM-4.0.0-update01-v100.zip --bulletin VEM400-200911014-BG,
ESXi400-200911201-UG --install
Enter username: root
Enter password: vmware
Please wait patch installation is in progress ...

The update completed successfully, but the system needs to be rebooted for the changes to be effective.

vSphere ESX/vCenter 4.0 Update 1

· ·

VMware just released ESX 4.0 Update 1 and vCenter 4.0 Update 1. Most people have already reported on this by now. Two things that stood out for me personally is the following:

  1. HA Cluster Configuration Maximum — HA clusters can now support 160 virtual machines per host in HA Cluster of 8 hosts or less. The maximum number of virtual machines per host in cluster sizes of 9 hosts and above is still 40, allowing a maximum of 1280 Virtual Machines per HA cluster.
  2. Enhanced Clustering Support for Microsoft Windows – Microsoft Cluster Server (MSCS) for Windows 2000 and 2003 and Windows Server 2008 Failover Clustering is now supported on an VMware High Availability (HA) and Dynamic Resource Scheduler (DRS) cluster in a limited configuration. HA and DRS functionality can be effectively disabled for individual MSCS virtual machines as opposed to disabling HA and DRS on the entire ESX/ESXi host. Refer to the Setup for Failover Clustering and Microsoft Cluster Service guide for additional configuration guidelines.

Especially the first is important as many people have been building non DRS-HA clusters solely for MSCS VMs. As of now this is not needed anymore. You can simply disable DRS and HA via the Cluster properties to make sure your MSCS VMs do not move around. I think Update 1 is an important release for everyone running vSphere at this moment.

Of course you View guys were all waiting for Update 1 to drop:

  • VMware View 4.0 support – This release adds support for VMware View 4.0, a solution built specifically for delivering desktops as a managed service from the protocol to the platform.

Full ESX 4.0 U1 Release Notes
Full vCenter 4.0 U1 Release Notes

Something else I noticed… The release notes for ESX talk about “vMotion” where the release notes for vCenter talk about “VMotion”. It seems that VMotion is about to be renamed to vMotion.

in the ghetto….

· ·

William Lam just updated two of his most popular scripts. If you haven’t looked at them yet, make sure you do as they are worth it. ghettoVCB(g2) enables the backup of virtual machines residing on either an ESX or ESXi host. ghettoVCBg2 is a complete rewritten and enhanced version of ghettoVCB or as William puts it “harder, better, faster, stronger”.

ghettoVCBg2

11/17/09 – The following enhancements and fixes have been implemented in this release of ghettoVCBg2. Special thanks goes out to Gerhard Ostermann for assisting with some of the logic in the ghettoVCBg2 script and the rest of the ghettoVCBg2 BETA testers. Thanks for everyones time and comments to make this script better!

Enhancements:

  • Email log support
  • Include/exclude specific VMDK(s)
  • Additional logging + dry run mode

Fixes:

  • Independent disk aware
  • Large VMDK backups

Original script, but updated with new features and a bug fix:

ghettoVCB

11/17/09 – The following enhancements and fixes have been implemented in this release of ghettoVCB. Special thanks goes out to all the ghettoVCB BETA testers for providing time and their environments to test features/fixes of the new script!

Enhancements:

  • Individual VM backup policy
  • Include/exclude specific VMDK(s)
  • Logging to file
  • Timeout variables
  • Configur snapshot memory/quiesce
  • Adapter format
  • Additional logging + dryrun mode
  • Support for both physical/virtual RDMs

Fixes:

  • Independent disk aware