Dec 102013

A nice vCOPs update which includes support for Hyper-V and dashboards for Exchange and SQL.  You can find the download here.  You can find the What’s New section from the release notes below:

Improved Enterprise Readiness

  • Optimized query execution to improve performance at scale.
  • Enhanced authentication options with new active directory integration for authentication.
  • Improved security with upgrades to the OS and runtime environment.

Expanded Integration

  • New integration with VMware Log Insight using a vCenter Operations Manager Content Pack that enables you to monitor your vCenter Operations Manager infrastructure.
  • Expanded integration with vCenter Hyperic using the vCenter Operations Management Pack for vCenter Hyperic. This management pack provides many new capabilities, such as:
    • Support for Microsoft Hyper-V servers, including out of the box dashboards for troubleshooting and performance analysis.
    • Support for Microsoft Exchange and SQL Servers, with out of the box dashboards for troubleshooting.
  • Several new management packs are available for download. Check the Cloud Management Marketplace on the VMware Solution Exchange for more details:
Jul 222013

Horizon Mirage is a part of the Horizon Suite from VMware and it is generating a lot of buzz.  I’m not going to go into the benefits why, you can read the link I’ve provided for that.  However, one of the most amazing things about Mirage is that it user a technology called sourced-based deduplication in order to backup all of the desktop endpoints.  Let’s talk about that technology, how it works and when it works best.

Source-based deduplication works by having a server in the datacenter with a lot of capacity attached to it.  We’ll refer to this server as the “repository.”  Now for the endpoints (which, in the case of Mirage, are Windows-based desktop/laptops.)  The client will begin by taking backups of the endpoints (Mirage calls them snapshots) and copying them to the repository.  It’s this process and how it works that is so amazing.  You would immediately think that when I take a backup of a endpoint that is 10GB on disk, the system will send 10GB over the network.  For the FIRST machine that you backup, it typically does.  It sends practically the whole image of the endpoint to the server for the first endpoint you backup.  It’s when you go to backup the second endpoint where the magic starts to happen.  Once the first endpoint has been “ingested”, for any additional endpoints added, the repository will use the data it has already seen to comprise all future backups.  I know this can be somewhat confusing, you can look at this article for some comparisons of different deduplication technologies.  For our example, let’s go a little deeper into exactly what happens during this process.

We will begin with the first Windows desktop that is 10GB on disk total and back it up.  The repository will “ingest” the files from the endpoint.  When it does this, it runs a hashing algorithm against the file to give it a hash code.  Once it does that for every file, the client also breaks the file into “blocks” or “chunks.”  It then runs a hashing algorithm against those chunks.  After all this it stores the backup down on disk in the repository.  Now, for the next (and every subsequent) client we want to backup or capture:  The client will ask the server for it’s hash table of files.  This is a small amount of data sent from the server to the client because the hash table is a list of all of the hash codes for all of the files in the repository not the actual data in the files.  The client then takes this data and analyzes each file on the second endpoint’s file system.  It develops a list of files that it has never seen before in the repository (and tells the repository which files are on this endpoint that the repository has seen before.)  Typical we see about 90-95% common files between images.  This is where it starts to get even more crazy efficient.  So the client has figured out which files the server already has in the repository and has told the server a list of those files that are on Endpoint #2 that the server has seen before.  Now the client looks at the files that the server has not seen before.  Let’s suppose there are 100 files that list that the server has not seen before.  The client will separate those files into blocks at the client (this is why it’s called sourced-based, the majority of the processing and checking for deduplicated data happens at the enddpoint, not the server).  So the client has separated the 100 files into blocks and runs the same hashing algorithm on the blocks.  Now the client compares the blocks to the blocks the server has in the repository and develops a list of blocks that the server has not seen before.  Let’s say the client finds 10 blocks that the server has never seen before.  It tells the server to mark down all of the blocks that are on this endpoint as being part of this endpoints backup.  Note: to this point in the process, the client has not sent any of the backup actual data to the server yet.  The last step is to take the blocks of files that are unique to this endpoint and compress them and send them to the server for storage, thus completing the backup, inventorying all of the common data and sending the unique data.

Whew!  What does all this look like in reality?  Let’s take a look at this log entry from a Proof-of-concept we are running for a customer right now:

Screen Shot 2013-07-21 at 10.17.42 AMThis is a initial first upload from a client to the Mirage repository.  This endpoint is running a Windows 7 base image.  It is about 7,634 MB on disk (listed by the total change size.)  Since this is the first time this endpoint has been backed up, all of the data on the endpoint is listed in the total change size.  On all subsequent backups, this capacity will be the size of the files that have changed since the last backup.  The next statistic is the killer number: Data Transferred is 29MB!  Mirage took a full backup of this system’s 7,634 MB and only sent 29MB (the unique data) over the network to the repository!

Here’s how it got there: Mirage inventoried 36,436 files on the endpoint that had changed since the last backup (all the files on the endpoint had “changed” since there was no previous backup of this endpoint.) Mirage ran the hash on all of those files and found that there were 2,875 files that it had not seen before in the repository  (the Unique Files number).  These 2,875 files totaled 221MB (the Size after file dedupe number).  Then Mirage pulled those files apart and looked for the blocks of those 2,875 files that it had not seen before.  Once Mirage found those unique blocks they wittled down the 221MB of files that were unique to 95MB of blocks that were unique (the Size after Block Dedupe number).  Mirage then takes the 95MB of unique blocks (which is the real uniqueness of this endpoint) and compresses it.  Every single step in processing at this point has happened at the client.  The last step is to send the unique data to the Mirage Server (repository).  This data sent is 29MB of actual data for a full backup! (the Size after compression number)  This whole process took 5 minutes and 11 seconds on the client.  This first backup of the endpoint will take longer because the hashing has to happen on all of the changed files (36,436 files for this backup).  However, all subsequent backups from this machine will only look at the files that have changed since the last backup because we already have a copy of the files that have not changed.

Where source-based dedupe works and where it does not

Sourced-based dedupe works the best when we have tons of endpoints with very similar OSes, apps and data (this is why it’s perfect for desktops and laptops).  Where source-based dedupe has it’s challenges is when the files are big and really unique.  Audio and video files are like this.  Unless the files are copies, no two video files are alike, at all.  Not all is lost if your users perform video or audio editing or just work with a lot of these files.  There are ways to accommodate that as well.  We would typically recommend using folder redirection or persona management to move those files to a network drive where we would backup with the typical methods and offload them from the endpoints.  We can also exclude certain file types from being backed up at all by Mirage.

Screen Shot 2013-07-21 at 11.14.29 AM

As shown above, Mirage includes an upload policy which allows you to set rules on file types you do not want to protect from the endpoints.  Some standard ones included already are media files (however as you see in rule exceptions, media files in the c:\windows directory will be backed up).

Mirage is definitely the way to go for any mobile endpoints or branch office endpoints where bandwidth limits and connectivity reliability make  VDI a less-than-optimal choice for the management a recoverability of these endpoints.  I don’t recommend products that don’t work as advertised.  Once the light bulb kicks on and customers understand this technology the real value of it shines thru.  Make no mistake, Mirage is not a mirage, it’s a reality and a really good one at that.

Jul 132011

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) Continue reading »
May 202011

I have been doing a number of presentations on vCenter Ops Manager over the past few weeks.  This concern was raised at one of the sessions.  If you were not aware, VMware had a promotion from November 23, 2010 to March 1, 2011.  The promotion was for 50 VMs worth of “Alive VM” (the product now known as vCenter Operations Manager.)  There were a set of VMware SKUs that were applicable for the promotion (unfortunately this was the link for it but it no longer works.)  I believe the SKUs were almost all of the upgrade or new purchases of Standard, Advanced, Ent or Ent+ editions of ESX.  I’m trying to find the list of SKUs but most of the links to detailed information are now broken.  So if you bought the applicable SKUs, you got 50 VMs worth of Ops Manager.

Beginning on March 15, 2011, VMware began sending out the email notifications with the Redemption Codes in email.  The customer contact on the original order for the products should have received the email.  It has instructions for redeeming the code and getting the Ops Manager licenses.  If you have not received (or can’t find) the email and believe you are eligible, you should contact your VMware Sales team.  Here’s the main point: If you have received your email, you only have until May 31, 2011 to redeem your code and get your licenses.

If you think you are eligible, make sure to find your email and get your licenses, time is running out.

Dec 022010

Note: Please read to the bottom for my take on the new releases.  As promised during VMworld Europe, just released is CapacityIQ 1.5.  As always you can find the download here.  Here’s the What’s New Section from the release notes:

CapacityIQ 1.5 includes the following new features and enhancements:

  • Storage Analytics – Adds disk space and disk I/O trending and storage analysis. The dashboard and views provide visibility into consumption of storage resources and ways to identify capacity bottlenecks. The data is optimized for vSphere and accounts for thin provisioning, I/O control, and linked clones.
  • Resource optimization – Adds storage-aware workload modeling and what if scenarios to forecast future capacity needs. CapacityIQ provides outlier detection and filtering capabilities for improved analytics.
  • Scheduled Reports – Adds report scheduling with email capabilities for automated delivery of capacity utilization and optimization reports.
  • Performance and scalability improvements – Improves the response time in the interface and raises the scalability limits to 6000 powered on virtual machines and 8000 registered virtual machines.
  • Virtual machine-based licensing – Supports virtual machine and CPU-based licensing. If you obtain a virtual machine-based license for CapacityIQ, install and manage the license from vCenter Server instead of the Administration Portal. You can continue to manage CPU-based licenses in the Administration Portal.

My initial take on it: Storage trending is a good addition.  It’s nice that it takes into account thin disks, etc.  Scheduled Reports is a nice add for proactive reporting.  Licensing going to vCenter for managing the license keys should have been done in v1.0.  I don’t like managing per-cpu licenses one way and per-vm another.  Overall sounds like a worthwhile release.  I’ll be plugging this into the lab later this week to kick the tires first hand.  Any additional pros and cons will be posted in an update.