Here’s a great resource to keep in mind as you’re planning your vSphere 4.0 deployment: “Reference Implementation: Clustering vCenter Server 4.0 Using Microsoft Cluster Services”. The tech note provides detailed steps for setting up a fresh installation of vCenter Server 4.0 in a MSCS environment, as well as upgrading an existing vCenter cluster setup on MSCS to vCenter Server 4.0. While this particular document shows the setup of a reference implementation using VMs for the cluster nodes, other variations would certainly also be valid.
For those of you who are already familiar with the procedure used to set up vCenter Server 2.5 with MSCS, I wanted to highlight how the procedure has changed with vCenter Server 4.0. With the release of vCenter Server 4.0, one of the main differences is that vCenter Server roles are now stored in Microsoft Active Directory Application Mode (ADAM) instances. During the MSCS setup process, you can simply use ADAM replication to replicate the roles from node 1 to node 2.
As we're all putting the final touches on preparation for VMworld, wanted to give a quick preview of some of the sessions at VMworld in the business continuity area. Probably many people headed to VMworld have already figured out their schedules, but given how many people buy their Christmas presents at the last minute I'm sure there are also quite a few people who haven't. Most of the session content will be posted to vmworld.com after the show, so anyone who has a subscription to vmworld.com (see http://www.vmworld.com/community/subscription/) or who attended VMworld will be able to see that even after VMworld is over.
Here's a list of a few sessions in the areas of availability, data protection, and disaster recovery that you may want to check out. Note that there are a large number of partners presenting at VMworld that you should also be checking out (see Schedule Builder to see all sessions), but since I'm not as familiar with the content of those sessions I'll be talking just about VMware-presented sessions.
According to this article it's providing a list of VirtualCenter actions that conflict with VMware Virtual Desktop Infrastructure (VDI) functionality and cause VDI Desktops to become inaccessible.
The following VirtualCenter tasks conflict conflict with VDI functionality and causeVDI Desktops to become inaccessible:
Moving an ESX from one cluster to another.
Removing and re-adding an ESX host from VirtualCenter
Un-registering and re-registering a virtual machine on VMware Infrastructure Client or VirtualCenter
Re-signaturing a LUN which is hosting VDI desktops
Moving virtual machines from one folder to another within VirtualCenter
Changing the names of folders in VirtualCenter where virtual machines are stored
Changing the names of folders in VirtualCenter where templates are stored
Upgrading VirtualCenter while VDM/View services are running
Re-installing VirtualCenter
To avoid losing access to VDI desktops, do not perform any of these actions.
