What’s New in vSphere 5.1: Technical Marketing Documentation and White Paper

What’s new in VMware vSphere 5.1? Here is Technical Marketing Documentation and White Paper. More enhancements from previous version.

VMware vCenter 5.1
VMware vSphere 5.1 – Networking
VMware vSphere 5.1 – Platform
VMware vSphere 5.1 – Storage
VMware vSphere 5.1 – Performance
VMware vSphere Replication White Paper
VMware vSphere Data Protection White Paper
VMware vSphere Storage Appliance

kouji@2012

Advertisements

ESXi boot tooks 2 hours

Problem suddenly happened after storage’s firmware has been upgraded and the bad thing was, Storage vendor failed to notice us early. Now pending on VMware Tech Support’s finding and the solution is far from over.

kouji@2012

Edited:

Seemed by marking “perennially reserved” on each RDM for devices participating MSCS clustering as recommended by this KB, the host finally able to boot with less than 6 minutes. Thanks VMware Tech.

VMware vCenter Site Recovery Manager is not supported for use with SVmotion and SDRS

Due to some specific and limited cases where recoverability can be compromised during storage movement, Site Recovery Manager 5.0 is not supported for use with Storage vMotion (SVmotion) and is not supported for use with the Storage Distributed Resource Scheduler (SDRS) including the use of datastore clusters. So be careful when you configure SDRS or do SVmotion in environments that has SRM.

SRM Release Note
VMware vSphere Blog

kouji@2012

VMware vCenter Site Recovery Manager 5.0 Best Practice Recommendations

VMware vCenter Site Recovery Manager (SRM) 5.0 has introduce new feature, vSphere Replication (VR) and made improvements on UI, Protection and Recovery time.
VMware vCenter Site Recovery Manager (SRM) provides advanced capabilities for disaster recovery management, non-disruptive testing, and automated failover. The following performance recommendations have been made in the VMware vCenter Site Recovery Manager 5.0 Performance and Best Practice Technical White Paper:

  1. It is recommended that the SRM database be installed as close to the SRM server as possible, such that it reduces the round-trip time between both of them. This way recovery time performance will not suffer greatly because of round trips to the database server.
  2. It is a good practice to have fewer but larger NFS volumes so that the time taken to mount a large number of such volumes decreases during the recovery. This might also translate to fewer protection groups on your setup leading to reduced recovery time.
  3. It is a good practice to have DRS enabled on a recovery site.
  4. More hosts lead to more concurrency for recovering VMs which results in a shorter recovery time.
  5. Also, before protecting VMs, bring recovery site hosts out of standby mode so that they get leveraged for creating placeholder VMs.
  6. Configuring VM dependencies across priority groups instead of setting per VM dependencies is usually the best idea because VMs within each priority group will be started in parallel.
  7. It is strongly recommended that VMware Tools be installed in all protected virtual machines in order to accurately acquire their heartbeats and network change notification. Refer to Advanced Settings/VMware Tools for more information.
  8. Make sure any internal script or call out prompt does not block recovery indefinitely.
  9. Specify a non-replicated datastore for swap files. This avoids wasting network bandwidth during replication between two sites and reduces remote calls to vCenter Server during a recovery to delete swap files for all VMs, which in turn helps in speeding up the recovery.

Consolidating Snapshot in vSphere 5

In vSphere 5 there is new command accessible through a click. From vSphere client, when we initiating Delete or Delete All operations on snapshot, the snapshot are deleted from Snapshot Manager, then the snapshot files are consolidated and merged to another snapshot file or to the parent disk of virtual machine. If fails, there were no snapshots shown in the Snapshot Manager, but the snapshot files were still being used on the datastore and this can cause the datastore run out of space. with vSphere 5, we can just right click virtual machine > Snapshot > Consolidate. But of course we need to know which virtual machine that we need to consolidate. Here are complete step:

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2003638

Note: the ESXi host that the virtual machine is registered on must be and ESXi 5 host.

p/s: Now on vSphere 5, we can SvMotion virtual machines with snapshots.

kouji@2012

VMware KB article about SvMotion / vDS / HA problem with vSphere 5

VMware KB team published the KB article that explain the problem around SvMotion / vDS / HA on vSphere 5. This is a known issue in vSphere 5.0 and also on vSphere 5.0 Update 1. For those running vSphere 5 and using VMs that attached to vDS might face this problem when SvMotion.

Symptoms:

  • A virtual machine remains powered off after an HA event
  • You are able to manually start the virtual machine
  • You may be using a vDS and have SDRS enable

The KB article now has a script attached in addition of work around which will help preventing problems until a full fixed is released by VMware. This script basically has been wrote by William Lam and has been fully tested by VMware.

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2013639

kouji@2012