There are 3 scenarios of MSCS clusters and ESX: Cluster-in-a-box (both MSCS nodes are on the same physical host – great for testing), cross-host (where each of the MSCS node VMs resides on different ESX hosts), and physical-virtual (where one MSCS node is physical, one is virtual).  The requirements for MSCS can change, even in the minor updates, so check the documentation often.  Here’s my compiled list of requirements/tips for MSCS on ESX 4.0:

• You are still limited to two-node clusters with MSCS on ESX 4.
• From a storage perspective, you can use local storage (for cluster-in-a-box) or Fiber Channel (for cross-host or physical-virtual clusters).  There is still no support for NFS or iSCSI (I personally think this is because FC and local storage have more predictable performance – although iSCSI is improving on this).
• If you are doing cross-host, both hosts must be running the same version of ESX (this just makes sense really).
• The MSCS node VMs cannot move as part of HA or DRS.  (HA is being a little redundant for MSCS, DRS is because MSCS is so hyper-sensitive to network connectivity that even a ping loss could failover the MSCS cluster).
• You cannot use MSCS with Fault Tolerance  (i.e. FT VM’s can reside on the same physical ESX hosts, but MSCS node VMs cannot run as FT pairs)
• You cannot vMotion MSCS node VM’s.  (Same reason as DRS).
• You cannot use N-Port ID Virtualization (NPIV)
• If you are using FC and using the native multipathing in ESX, you cannot use round robin as a path policy.
• You must use VM hardware version 7 with ESX/ESXi 4.0 (if you migrated the VMs from ESX 3.5 or before, make sure to upgrade your VM hardware version)
• Failover clustering with Windows Server 2008 is not supported with virtual compatibility mode RDM’s, for Win2008 use physical compatibility mode RDMs.
• You cannot use thin-provisioned disks for the Windows OS vmdk’s, they have to be thick.
• For Win2000 and Win2003 use LSI Logic Parallel as the controller type for the shared storage.  For Win2008 use LSI Logic SAS.
• For physical-virtual MSCS clusters, use RDMs in physical compatibility mode (this just makes sense if you think about it)
• You cannot run storage multipathing software in the VMs or on ESX (i.e. no PowerPath VE).
• You cannot over-commit memory for the MSCS node VMs, set the Memory Reservation option for each of the nodes to the amount of memory assigned to the virtual machine.
• Set the disk I/O timeout to 60 sec. or more (HKLM\System\CurrentControlSet\Services\Disk\TimeOutValue) in the registry.

You can find all the details and steps walking you thru the setup of MSCS on ESX in this article .  If you’re not on vSphere yet but you want to run MSCS nodes as VMs, you can find the proper docs for your version of ESX in a freshly updated KB article located here .

What does Fault Tolerance do to prevent a split brain if both Primary and Secondary VMs become isolated?

Fault Tolerance (FT) uses an on-disk generation number file.  When FT is enabled the primary VM creates a file on shared storage called generation.N where N is a counter number.  The secondary VM is started and when it connects to the primary, the primary tells the secondary what the generation number is.  Once the Primary or secondary detects that there is a failure in the other half of the VM pair, it will try to rename the generation.N file to generation.N+1.  If the rename succeeds, the VM takes over as being the Primary (or remains the primary if it already was) and takes corrective action to rebuild a secondary and become protected again.  If the rename of the generation.N file fails, that means that the other VM in the pair already renamed the file and took over and the current VM shuts down.

There you have it, the disk subsystem prevents both VM’s from becoming the primary at the same time and creating a split brain.

vCenter 4.0 build: 162902

The wait is over!  vSphere is out and available!  Go get it here !

You can read all of the details in the white paper here .

vCenter 4.0 (vCenter is now 4.0 to be on par with ESX) includes linked mode in the standard edition of vCenter.  Those users who have current support on vCenter standard edition will receive linked mode as part of their included subscription.  Linked mode is not included in the foundation edition of vCenter or in the vSphere essentials editions .  Linked mode uses a ADAM (Active Directory Application Mode) database to replicate it’s configuration between multiple vCenter servers.  Some of the things stored in the ADAM database include:

• Connection information (IP addresses and ports)
• Certificates and thumbprints
• License Information
• User Roles

When vCenter servers are "linked," connecting to any one will allow an administrator to see and manage any of the vCenters in the link group thru one vSphere Client assuming they have rights to do so (as seen below).

Permissions can be configured so that an admin may only have rights to certain vCenter servers in the link group and not others.  The scalability has also been increased dramatically.  A single vCenter instance can manage 300 ESX hosts and 3000 VMs.  A linked mode group can manage 1000 ESX hosts and 10,000 VM’s (now you know why a search field was added to the client.)

You can read about linked mode and all of the new features in vCenter here .

1. Receive activation code in email
2. Go to license portal
3. Generate a new license file
4. Choose server or host based file
5. Select license quantities to activate
6. Download or email license file
7. Install license server if needed
8. Upload license file to license server
9. Re-read license file to server
10. Configure licensing in VC/ESX UI
11. Product activated.

The great news is that this has been drastically simplified in vSphere 4.0.  Licenses are now delivered as 25-character keys.  The procedure now looks like this:

1. Receive license keys in email
2. Enter license key into vSphere Client GUI
3. Assign licenses to ESX hosts
4. Product activated.

Here’s a shot of what the new licensing config looks like in the new vSphere client:

This definitely got the biggest "Thank You" from the audience.  The license server will still be available in vSphere 4.0 so that you have backward compatibility.  For instance, if you wanted to run some ESX 3.5 and some 4.0 together.  vCenter 4.0 will be required to manage both versions of ESX together (vCenter 2.5 cannot manage ESX 4.0 hosts however vCenter 4.0 is backward compatible).

Not a ground-breaking feature by any means, but one solving some pain that customers have felt for a long time.  Enjoy, reports about more of the new features coming soon.  Next up: vCenter Linked Mode

Stephen talked about the main focus of VMware.  That is, to enable customers to deliver IT as a service, at the same time remembering 3 key factors:  Efficency, Control, and Choice .  He went on to discuss vSphere.  He gave some awesome statistics on vSphere, particularly: over 3 million Engineering hours have gone into vSphere .  For the Efficiency section, he discussed the scalability and performance.  He talked about power savings and storage savings .  For Control , he talked about Config-Control and how to maintain consistency in host configuration.    He then discussed distributed switches and how they add control to the networking layer.  vApp and how it will let admins control their apps better as a single unit.  He then went on to demo a very polished Fault Tolerant configuration.  This was received very well and with a resounding applause from the crowd.  He talked about vShield Zones and how they protect applications from talking to the infrastructure that they shouldn’t for customers without advanced firewall experience.  Lastly, Choice .  The goal is to allow any server, any storage, any OS, and any app to run local in the private cloud or a cloud in a different location, public or private.  He showed a list of the supported OSes for vSphere compared to those of Hyper-V and it was not even close.  I guess it is an advantage to not have an OS business.

After the functionality section Stephen introduced Bogomil Balansky (below), VP of Product Marketing, VMware.

Bogomil introduced the Partners to the licensing and packaging of vSphere.  I apologize, due to legal restrictions I cannot list those here.  Hopefully we will find out more information from the announcement coming April 21st .

Stephen returned to the stage and discussed the API and plug in capability of vSphere which was a great segway to the next presenters: Adam Famularo (below on left) SVP and GM, Recovery Management and Data Modeling Business Unit, CA, and the second presenter was Roger Pilc (below, seated), Corporate SVP and GM, CA.

Adam showed a great video on the University of Texas, Brownsville, and how they used CA XOsoft to recover their MS Exchange environment on VMware at their disaster recovery site during Katrina.  He went on to discuss CA’s organization and how they are all aligned.  He discussed many of the channel programs that are available (this is a Partner conference after all).  He talked about upcoming Arcserve and XOsoft releases.  I apologize, I don’t know what is public or not from the information that was presented so I’m going to leave the details out on that one.  Roger took the lead at this point.  He discussed the cloud and how it is transforming business.  That management is one of the key pieces needed to take it to the next level.  He closed with an explanation of the VMware – CA relationship and how that joint effort can truly improve overall service quality from the cloud.

Now onto my labs today, I’ll check back in soon.