The VMguy

As you probably know by now SRM5 is just over the horizon.  You have probably heard me mention numerous times how SRM has always been my favorite non-vSphere product from VMware.  Some great news is that they have made some great improvements in SRM5 and added the most-requested functionality.  Here we go:

• vSphere Replication – The biggest feature add.  An additional replication option which allows you to replicate your VMs without having the storage perform the replication.  Even allows you to replicate to/from local storage on the ESXi hosts.  There are some important limits to vSphere Replication.  It’s not for everything/everyone but it does do quite a bit for the first release.
  • Requires vSphere 5
  • Managed from the vSphere client directly
  • ISOs and Floppys are not replicated
  • Powered off/Suspended VMs are not replicated
  • Non-critical files are not replicated (swap files, dumps, logs, etc.)
  • VMs can have snapshots on the protected side but they are automatically collapsed on the recovery side
  • Physical RDMs not supported (but virtual RDMs are)
  • Fault Tolerant VMs, Linked Clones and VM Templates are not supported
  • Automated Failback of vSphere Replicated VMs is not supported in SRM 5.0
  • Requires VM Hardware version 7 or 8 (required for Change Block Tracking)
  • Supports up to 500 VMs
  • Asynchronous only
  • Minimum replication frequency is every 15 minutes, max is every 24 hours
  • Initial copy can be seeded by sneaker net (taking the initial on a portable HD and importing at the destination, i.e. does not need to seed the initial copy over the wire)
  • File-level consistency (except for planned migration – see below) quiesces OS file system before sending changed blocks to the DR site (does not quiesce applications)
  • Included in both Standard and Enterprise Editions of SRM
  • vSphere Replication is not available outside SRM5
• Scalability Improvements
  • 1000 Total Protected VMs (Same as SRM4.1)
  • 500 Protected VMs in a single protection group (same as SRM v4.1)
  • 250 Protection Groups (Up from 150 in v4.1)
  • 30 Simultaneous running recovery plans (Up from 3 in v4.1 – this is the biggest improvement in scalability)
• Planned Migration – This is a big feature add.  This is another option when you are going failover.  In 4.1 the only option was to start up the VMs from the last good replication and go.  This option now allow you to migrate when there is an impending disaster and the protected side is still up.  Planned migration will shut down the VMs on the protected side then initiate a replication of the storage frames (or vSphere Replication) to get the last drop of changed data to the recovery side before powering on the VMs and bringing them up.  One extremely important advantage to this method: the VMs are always in a application-consistent state when they come up in DR.  (Absolutely love this feature)
• Failback – the single most-requested feature in SRM4.  Once a failover occurs, the admin clicks the “Reprotect” link to reset the recovery plan for failback and reverse replication.  Once completed, the recovery plan can be tested or run in the reverse direction and recovery the VMs to the origional protected site.  (This is outstanding for enterprises that are required to do a true failover for DR testing.
• User Interface improvements – Slightly different look and feel.
  • both sides are visible without vCenter linked mode
  • IP changes for VMs during recovery can now be entered in the GUI (thank you VMware!)
  • Placeholder VMs at the DR side now have a unique icon (with a thunderbolt thru it) to identify them easily in the DR vCenter.
  • Reports now include the user ID that initiated the Failover or DR test.
  • Reports now include more information about the storage steps (including the device friendly names)
• IPv6 Support – Ipv6 is now supported for all links.
• IP Customization performance increase – big performance improvement in the actual IP conversion in the VM
• In guest callouts – now you can run a script inside the VM, run a script on the SRM server or insert a breakpoint to post a message (these also now have maximum timeouts as an option) during the recovery plans
• New APIs on both the Protected and Recovery Sides – new commands for 3^rd party integration (note these are SOAP based and not PowerShell or PowerCLI)
• Dependency Improvements – There are now 5 priority groups for each recovery plan.  Each priority group has to finish completely before the recovery plan will start with the next group.  Within a single priority group, you can also set dependencies (similar to how Windows Services set dependencies) so that a particular VM will not recover before it’s dependencies have recovered (note-this is within a single priority group and cannot span priority groups.)
• Licensing – There are now two editions of SRM, Standard and Enterprise.  Both are feature identical.  Standard is for sites up to 75 VMs and Enterprise is for sites up to 1000 VMs (the technical limit).  All existing customers who maintain support will get SRM Enterprise when they go to SRM5.  SRM Standard is a new offering for SMBs and Remote Offices.  When customers need to grow beyond 75 VMs at a site, they can upgrade their existing VMs to SRM Enterprise and then continue buying SRM5 Enterprise VM-Packs.  Licensing still sold in packs of 25 VMs.  Only need to purchase for the VMs that you are going to protect.

Unless you’ve been under a rock this past week you have probably heard about the licensing changes that VMware has delivered with vSphere 5.0.  Many of my customers have reacted negatively to the new licensing saying that they won’t fit into the new model.  When I asked my customers what their vRAM footprint was, most customers could not begin to guess what they were using.  Here’s how you can tell from vCenter with a quick export into Excel and a few formula tweaks:

Go into your vCenter (if you have more than one, you will need to do this for each.)  Go into the “Hosts and Clusters” view.  On the left pane, select the vCenter Server itself.  On the right pane, select the “Virtual Machines” tab.  You can optionally click the “State” field title to sort by state.  You may also click the host field to sort VMs by the host names (I would recommend this if you have multiple clusters with multiple editions of ESXi).  You can then right-click the virtual machine titles and add the field for “Memory Size” as shown below.  Right-click right on the word “State” in the title of the column.

Once the Memory field has been added (it will probably be far on the right), drag the filed so it’s just to the right of the “State” field.  Now go to the “File” Menu at the top of the vSphere client and select “File” then “Export” and then “Export List”.  Export the file selecting “Excel Workbook” as the file type.  Once exported, open the list in Excel.  In Excel, add a column to the right of the memory column like so:

Edit Cell D2 and put in this formula:   =IF(B2=”Powered On”,VALUE(LEFT(C2,(LEN(C2)-3))),0)

Copy this formula down the entire column.  This checks to see if the VM state is powered on (you do not draw from your vRAM license if it is not).  It then removes the “MB” and converts the value to a numeric so you can sum them up.

Scroll down to the last row and edit the cell in the next empty row in the memory column to something like this:  =ROUNDUP(SUM(D2:D65)/1024,0)

Where D65 is actually the last cell with the memory data in it, your row number will vary depending on how many VMs you have.

The ROUNDUP will round up the memory allocation (in case you have some VM’s with 4000MB allocated to them instead of 4096MB) and you need to divide the sum by 1024 to convert to GB of vRAM.

If you would rather run a PowerCLI script to gather the info, you can find a great article on how to do it here.

I hope your number turns out ok.  If it does not, all is not lost.  There are ways to shrink your vRAM footprint so the impact of the licensing is not as bad.  If you would like me to have a look, email me, I can provide a service to see how much vRAM you have allocated but never use.  That may prolong the next license purchase a bit or perhaps soften the expense.  The new licensing does not need to always be negative, maybe we just need to learn how to size our VMs with the licensing in mind.

UPDATE: If you copy and paste these formulas into Excel, the ASCII is different for some reason.  Just backspace over the quotes (“) and readd them.  The quotes are what Excel has an issue with.

VMware saw an issue with the SMB customers in that some were not adopting the higher editions of their software because most of the features required shared storage and some SMBs might not have been ready to bite off the costs of that storage.  So VMware decided to get creative and create a redundant shared storage solution using local storage.

Here are some of the features:

• Deploys as an appliance, very easy to install
• Must be deployed on a new ESXi 5.0 installation
• Deploys a VSA Cluster Service on the vCenter server
• The VSA Cluster Service can deploy the VSA “Agent VMs” to each of the ESXi 5.0 hosts
• The appliance will use the local space available and present the storage on the network as an NFS datastore
• Replicates the local storage to the local storage on another host in the cluster for redundancy.
• If a host fails, the appliance storing the replica will immediately take over the failed “Agent VM’s” IP address and share the storage from the replica
• v1.0 supports 2 or 3 ESXi hosts in a cluster (Typically for the essentials kits)
• Sold as a separate SKU with one price with no license capacity restrictions (no technical size limits that I could find)
• Supports 25 VMs (configured on 2 ESXi hosts) or 35 VMs (configured on 3 ESXi hosts)
• It is the only scenario where VMware recommends running vCenter on a physical or standalone ESXi hypervisor (To protect you from running into a Catch-22 as vCenter is managing the VSAs
• Recommended to use RAID10 on the hardware RAID controllers in the hosts (to protect from a single drive failure)
• Uses RAID 1 (Mirroring) between hosts for redundancy
• Supports Storage vMotion for when you are ready to migrate to hardware shared storage
• Can put the whole VSA cluster in maintenance mode or just a single node.  Can also replace a node and have the VSA rebuild onto it for redundancy or for rolling upgrades.

Here’s how it works: Imagine I have 3 hosts numbered 1,2 and 3.  Once the VSA gets installed, it creates two volumes on the available local storage on each host.  So host 1 will have volumes 1A and 1B, host 2 has 2A and 2B, host 3 has 3A and 3B.  Once the VSAs are configured, they will be redundant so that 1A (which stores VMs) mirrors to 2B, 2A mirrors to 3B and 3A mirrors to 1B.  If any VSA get’s dropped, the VSA running the mirror copy takes the IP address of the failed VSA and keeps right on chugging.

My Take

The Pros: Great solution for SMBs without shared storage to take advantage of HA, vMotion, etc.  I also think this is an outstanding solution for companies with remote offices who want to have redundancy in 2 or 3 ESXi hosts but don’t want to put shared storage in each site.

The Cons:  Way too much overhead.  VMware is recommending hardware RAID10 from the local drives if possible.  If I have 4 x 1TB drives in a server (4TB RAW disk capacity).  I use RAID10 as per VMware’s recommendation, this means 2TB gets presented to the ESXi host.  Now the VSA uses half of that storage for VMs and half as a target to mirror the VSA from one of the other hosts.  So out of 4TB of RAW disk, I get <1TB of capacity to store VMs on (don’t forget, I need room to store ESXi itself).  Thats a 75% reduction from RAW capacity = too much overhead.

Overall I still think it’s worth it.  It’s still going to be less expensive that a shared storage frame (even with the overhead loss).  I think for remote sites, you can’t beat it.  I can’t wait to see what they add to it in v2.0.

As I was wading thru all of the new materials from yesterday, I thought it would be helpful to create a big list of all of the new features in vSphere 5.0.  There were really only a few named in the presentation (or else the preso would have been 3 hours and put the analysts to sleep).  While we wait for the release notes, I put together this list for you.  This is not every new feature, but rather as many as I could find or remember.  I’ve also added a quick blurb on what that feature does and my comments in parenthesis.  If you are aware of something that I missed, please add in the comments below (with your own comments/opinions of course).  Here we go:

VMware vSphere 5.0

• ESXi Convergence – No more ESX, only ESXi (they said they would do it, they meant it)
• New VM Hardware:  Version 8 – New Hardware support (VS5 still supports VM Hardware 4 & 7 as well if you still want to migrate to the old hosts)
  • 3D graphics Support for Windows Aero
  • Support for USB 3.0 devices

• Platform Enhancements (Blue Requires Hardware v8)
  • 32 vCPUs per VM
  • 1TB of RAM per VM
  • 3D Graphics Support
  • Client-connected USB devices
  • USB 3.0 Devices
  • Smart-card Readers for VM Console Access
  • EFI BIOS
  • UI for Multi-core vCPUs
  • VM BIOS boot order config API and PowerCLI Interface
• vSphere Auto Deploy – mechanism for having hosts deploy quickly when needed ( I’m going to wait and see how customers use this one.)
• Support for Apple Products – Support for running OSX 10.6 Server (Snow Leopard) on Apple Xserve hardware. (although I betting technically, you can get it to run on any hardware, you will just not be compliant in your license) Read the rest of this entry »

A new version of the vSphere Client was release thru the iTunes Store and can be found here.  Here’s the What’s nNew section from the details in iTunes:

New in version 1.1.0

• Support for connecting directly to a vSphere host (resolves Null Pointer Exception)
• Integrated interface to input vCMA server settings and login credentials
• Enhanced version compatibility checks between vSphere iPad application and vCMA server
• Fix for Null Pointer Exception when rebooting a host while the host was in maintenance mode
• Store password, if requested by the use, in the keychain
• Ability to properly scroll the host list in landscape mode
• Sorted host list (by name and grouped by vendor ID)
• Display either ellipsis for long virtual machine names
• Better performance metricswhen connecting directly to a vSphere host
• Show “Unavailable” or “PoweredOff” message when unable to obtain performance data for a selected VM
• Reflect available actions correctly, for a selected VM, when an operation was completed
• Ability to cancel “revert to snapshot” action

My notes:  The client is maturing, slowly, worth a look but I typically only use it when in a pinch and need some simple tasks completed in the environment.