VMware released vSphere 4.1 with a couple of new features like “Memory compression”, “Storage I/O Control” and much more. I’m not going to repeat all the information, because you can already read it here:

• Gabesvirtualworld
• Jase’s Place
• vSphere-Land
• VMware

One thing that I don’t read is that vMotion is now part of vSphere Standard edition. And that’s a big improvement for a lot of organizations who don’t need all the features of Advanced or Enterprise (Plus), but do need vMotion for maintenance for example. 

NetApp just announced the release of the Rapid Cloning utility (RCU):

NetApp is proud to announce the release of the Rapid Cloning Utility 3.0.  This release brings many new features to assist virtual data center administrators with managing their server and desktop environments to further reduce management overhead associated with traditional storage deployments.

Here is a list of some of the new or expanded features and support for RCU 3.0:

• VMware vSphere 4.0 support  
• VMware vApp support
• Data ONTAP 7.3.2, 7.3.3, and 8.0 7-mode support
• MultiStore support (requires Data ONTAP 7.3.3)
• 64-bit platform support
• Automatic import wizard into VMware View 4
• Create export file for Citrix XenDesktop 4.0
• Re-deploy VMs from a baseline image
• Create clones in qTree-based datastores
• Create clones in designated VM folders
• vCenter alert for misaligned source VM
• ‘Add storage system’ wizard with option to change attributes
• API enhanced to create, destroy and resize datastores, as well as re-deploy VMs
• Select virtual hard drive type (thin or thick) for clones
• Match guest host name to VM name when using a Customer Sysprep Answer File
• Clone nvram with VM
• Improved security for NFS datastore export

Read the rest of the announcement of the release of NetApp Rapid Cloning Utility.

The “Project Virtual Reality Check” team just released a new whitepaper: “Hyper-V 2008R2, vSphere 4, XenServer 5.5 on Intel ‘Nehalem’ Xeon 5500“. 

 “If you are looking for an independent advise and a ‘Reality Check’ in relation to Virtualizing Terminal Server and Desktop workloads, if you are curious about the impact of different hypervisors and the performance differences with various hardware and if you are searching for best practices for your virtual Desktops … Project VRC whitepapers are a must read!”

• Highlights, performance differences and best practice conclusions for Terminal Services workloads on:
  • Bare metal Terminal Services; 2003/2008/x86/x64
  • Hypervisors: Citrix  XenServer 5.5, Microsoft Windows Server 2008R2 ‘Hyper-V’ and VMware vSphere 4.0
  • Performance impact using different HP Proliant state-of-the-art hardware using Intel Xeon ‘Nehalem’ x5500  Read the rest of this entry »

Not a lot of info is found when you Google for manually selecting/fixing the primary HA nodes in a VMware VI or vSphere environment. Of course Duncan Epping has a couple of extremely interesting posts on Yellow-Bricks.com concerning HA even when it comes down to selecting or promoting the HA status of ESX nodes (a must read!), but I want more …

Let’s start with what I assume to know about HA:

- HA works with primary and secondary HA nodes
- The primary nodes are aware of the states and configs of all nodes in an HA cluster
- The secondary nodes depend on the primary nodes
- There is an supported limit of 5 primary HA nodes per cluster
- The first 5 ESX hosts that are added in a HA cluster are initially defined as primary HA nodes
- All the other hosts that are added to the HA cluster are configured as secondary HA nodes
- There’s a way to configure a HA node as primary or secondary, however it’s not possible to configure an ESX host as a “fixed” primary HA node:
Read the rest of this entry »

Last month I was on-site at one of my customers and experienced a major problem on the vSphere environment. We suddenly experienced about 150 virtual servers running on 16 hosts in 2 clusters (on the same SAN) going in jabber-mode. They froze, which made them unavailable for pings and other traffic. The freeze moment varied from 1 to 30 seconds. After that the VM’s went back on-line again. This seemed to happen in groups of about 10 to 30 VM’s.

Pretty soon we saw in the logs that a VMFS LUN was removed by one of the SAN administrators. This LUN was still attached to all the ESX hosts in that cluster but was not “in use”, meaning, there were no VM’s running on it.

Off course the unclean removal on SAN-level of a LUN before detaching it from the ESX hosts is not the way to do this but that what I just described shouldn’t have happend!

The quick solution was Read the rest of this entry »