As of VirtualCenter 2.5 Update 2, you can create a clone of a powered-on virtual machine without any downtime to the running virtual machine.

The mechanism for Live Cloning goes something like this>>

• Whenever user selects “Live clone…”, create a snapshot (using VIM). Increment the snapshot counter for this.
• If the user does a clone of this VM, create a delta disk off the snapshot delta disk.
• The snapshot is protected so the user does not inadvertently destroy the snapshot chain.
• If consolidate is called on a chain with snapshots generated by live clone, then the snapshots will be collapsed. Nothing special here, since the delta disks already have this relationship set up, so the consolidate should just work.

The snapshot taken is a quiesced snapshot and first attempts to use the sync driver to check the I/O state. However, with transactional applications, such as MS SQL Server, the I/O may not stop/pause long enough for the sync driver to work properly. (This is similar to potential issues encountered with VCB.)

Because this is the method used to implement Live Cloning it is best to not use Live Cloning on VMs with transactional applications.

After upgrading to Virtual Center 2.5 Update 2 you may notice that guest VMs no longer automatically VMotion off the host when you attempt to put it in Maintenance Mode.

This is a new behavior introduced in Update 2.

Virtual Machine Migrations Are Not Recommended When the ESX Server Host Is Entering the Maintenance or Standby Mode

No virtual machine migrations will be recommended (or performed, in fully automated mode) off of a host entering maintenance or standby mode, if the VMware HA failover level would be violated after the host enters the requested mode. This restriction applies whether strict HA admission control is enabled or not.

The solution is to either disable HA on the cluster, or migrate the machines manually. Once all machines are off the host, it will go into maintenance mode.

The release notes mention this here: http://www.vmware.com/support/vi3/doc/vi3_esx35u2_vc25u2_rel_notes.html#knownhaissues

Think you have enough HA capacity that this is not your problem?  Try un-configuring HA on your cluster and test. If it goes into Maintenance Mode after this, then this is indeed it.

My understanding is that this will be corrected in a future release but don’t hold me to it.

If you ever have trouble starting Virtualcenter check the logs.

C:\Program Files\VMware\Infrastructure\VirtualCenter Server\Logs

Look for this message:

[2008-01-17 01:05:43.917 'App' 304 error] Unable to get exclusive access to VC repository.

This means there are some connections to the virtualcenter database (repository) that need to be freed before virtualcenter can use it. It will not start until it can get this exclusive access.

You can either restart the entire database server or locate any connections to the database and terminate them.  Then restart the virtualcenter service.