VMware vCenter™ Infrastructure Navigator is an application awareness plug-in to vCenter Server, and provides continuous dependency mapping of applications. Infrastructure Navigator offers application context to the virtual infrastructure administrators to monitor and manage the virtual infrastructure inventory objects and actions. Administrators can use Infrastructure Navigator to understand the impact of the change on the virtual environment in their application infrastructure. Infrastructure Navigator helps virtual infrastructure administrators perform the following tasks:

• Make accurate first-level triage to help either eliminate the problem or associate the problem with the virtual infrastructure when business service users report problems.
• Assess change impact, manage, and communicate virtual infrastructure issues for critical applications.
• Understand the application and business impact of changes to the virtual infrastructure on applications.

The Open Source Licenses (OSL) file for the virtual appliance is available at /root/open_source_licenses.txt. You can retrieve the file by running the scp root@<appliance IP>:open_source_licenses.txt command.

Infrastructure Navigator is supported on vCenter Server 5.0 with the vSphere Web Client. The supported ESX versions include ESX/ESXi 3.5 (build 425420), ESX/ESXi 4.0 (build 398348), ESX/ESXi 4.1 (build 433742), and all builds of ESXi 5.x.

Features

This section describes the key features for the Infrastructure Navigator 1.0.0 release.

Simplifies and automates the deployment and the discovery process and keeps manages Application Component Knowledge Base (KB) current

• Eliminates physical switch spanning or credential based discovery.
• Discovers and maps the application components and dependencies using KBs and presents this knowledge through maps or search for relevant use cases.

Provide Infrastructure Navigator data for vCenter Server and related solutions

• Ensures that the application and dependency data is available to the rest of the vCenter Server entities and its various solutions through the vCenter extensibility APIs.
• Supports SRM integration to set up more focused and accurate site recovery and backup plans.

To enable Network I/O Control we need to have a DvS in place.  If we select the distributed switch and then select the Resource Application tab on the right, this gives us the “properties” option on the far right.  By selecting the Properties option, you can enable Network I/O Control on the DvS.  Once enabled you can see all of the System network resource pools.  There is one at the bottom of the list labeled “vSphere Replication (VR) Traffic”.  Selecting it and then clicking the “Edit Settings” link just below it opens up the settings window.

From here, you can edit the adapter shares.  The shares are to balance the bandwidth so that network flows can use the bandwidth thats available from a given dvuplink.  The shares are for a given dvUplink.

Alternatively, you can uncheck the Unlimited checkbox and set a host limit.  Keep in mind that this is Megabits per sec, not MegaBytes.  This is also the limit of the combined set of dvUplinks on a given host.

Lastly, a QOS priority tag can be used.  The traffic will have a 802.1p tag applied to it.  The IEEE does not standardize or mandate the use of the priority tag applied to the packets but the switches should treat higher tags with higher priority.  The choices are None, 1-7.

While not the granular controls that we may wish for, say individual bandwidth controls on a per VM or per-site replication limits, these settings and options are a start.  Hopefully in the future in vSphere Replication v2 we will have more granular controls for bandwidth throttling but until then, these are what we can use.  Happy computing.

VMware vCenter Site Recovery Manager 5.0 enhances your ability to build, manage and execute reliable disaster recovery plans for your virtual environment. With the release of version 5.0, VMware has expanded the capabilities of Site Recovery Manager to provide unprecedented levels of protection. New use cases have been made possible through the addition of the following capabilities:

• vSphere Replication. When used in conjunction with VMware vSphere 5.0, Site Recovery Manager 5.0 introduces a new capability to utilize the vSphere 5.0 host to perform replication of powered-on virtual machines over the network to another vSphere 5.0 host, without the requirement for storage array-based replication. As virtual machines change with use, the changed blocks are replicated to a shadow copy of the virtual machine resident at the recovery site, in accordance with a Recovery Point Objective set as a property of the virtual machine itself.
• Planned Migration. A new workflow designed to deliver migration while minimizing the risk of data loss. Planned migration will stop the workflow from continuing if an error is encountered, providing an opportunity to fix the problem, ensuring that systems are properly quiescent and that all data changes have been completely replicated.
• Automated Re-Protection. Re-protection is a new extension to recovery plans for use only with array-based replication. Automated re-protect enables the environment at the recovery site to establish replication and protection of the environment back to the original protected site through a single click.
• Automated Failback. Automated failback returns the entire environment to the originally protected primary site. This can only happen after re-protection has ensured that data replication and synchronization have been established to the original primary site. Failback will run the same workflow that was used to migrate the environment to the protected site, ensuring that the critical systems encapsulated by the recovery plan are returned to their original environment. Automated failback, like re-protection, is only available for use with array-based replication protected virtual machines.
• Enhanced Dependency Definition. This includes the addition of more (5) priority groups, and the ability to set virtual machine dependencies within a priority group. Virtual machine dependencies can be defined to ensure that required systems are available before dependent virtual machines are powered on. This enables highly organized workflow control, ensuring that required services are available before dependent virtual machines are powered on.

• 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.

Here’s why:  In a true failover in SRM, the first step of the Recovery Plan is to shut down all of the VMs in the primary site that are protected.  This is so that when the VMs restart in the recovery site, they do not conflict on the network with the original VMs.  Here in Miami the typical disaster is, of course, hurricanes.  Hurricanes are typically predictable with a decent notice.  I can then assume that my odds are higher than normal that when the person hits the failover button here, both sites are still available and I will be avoiding a disaster and not recovering from one.  For this reason, I recommended to my customer that they add a message in their recovery plan right above “Prepare Storage” in the Recovery Plan.  You can do this by right-clicking “Prepare Storage” and selecting “Add Message”.

I added the following message to their Recovery Plan:

License Sale

Upgrade to vSphere Enterprise for $495 per CPU (normally $685/CPU) – Support and Subscription is required with purchase.  Pretty self-explanatory on the differences.  I’m a huge fan of Host Profiles, distributed switches and storage IO control.

50 Seats of View Premier with vSphere Enterprise Plus Upgrades – Customers who purchase Enterprise Plus (Ent+) will get 50 concurrent Desktops of View Premier Edition and 1 year of Production Support and Subscription.  This promo also includes all of the bundles that upgrade vSphere to Ent+ (including the $495 upgrade above).

15 VMs of CapacityIQ with upgrades to Standard, Advanced, Enterprise and Ent+ – Customers who purchase or upgrade upgrade to any of these editions or bundles containing any of these editions get 15 VMs of CapIQ.  Essentials and Essentials Plus bundles are not eligible.

The official disclaimer from VMware: “VMware reserves the right to amend the terms, conditions and requirements of these promotions.  List Pricing is for reference purposes only and is subject to change without notice and my vary within region. Please refer to your reselling partner or www.vmware.com for a quotation or actual product pricing.”

PerVM Licensing

CapIQ, AppSpeed, Chargeback, and Site Recovery Manager are switching to perVM licensing from perCPU.  Customers can stay on their perCPU licenses or they can convert.  Customers who convert will get 10 VMs of Appspeed for each CPU, 10VMs of CapIQ for each CPU, 20 VMs of Chargeback for each CPU and 5 VMs of Site Recovery Manager per CPU, respectively.  As I mentioned, customers can stay on their existing licenses and renew support for them if they want.  They will not be able to buy any new perCPU licenses after December 15th, 2010 for these 4 products listed above.  This is where I see a bit of a storm brewing.  Customers who run many VMs per host and want to protect most of them are in for a bit of a rude awakening.

My take on PerVM Licensing

Let’s say a customer runs SRM perCPU today.  They have 4 hosts running 100 VMs total and SRM protects them all.  Each host has 2 CPUs.  In the old licensing model, they needed 8 CPUs of SRM that retailed for $1,750 each.  8 x 1,750 = $14,000 (let’s exclude Support and Subscription for the moment to make the numbers easier but I recognize that SnS is required).  Under the new model, the PerVM licensing comes in packs of 25 VMs.  For our example we need 4 packs of 25 VMs that retail for $11,250 each or 4 x 11,250 = $45,000.  Yes, you just read that right.  The customers cost for SRM in our example just went from $14k to $45k.

The new licensing does benefit some customers however.  Those with large farms that want to protect a minority of their VMs.  Those customers can now just buy a pack of VMs and protect only the ones they need.  They can even split the licenses between sites and cross-replicate.  This is where this licensing model really helps.  It helps the customers who just want to do some SRM.

The last point I want to make is buried in the FAQ on PerVM Licensing.  If you are currently running perCPU SRM in a cluster, if you need to add a host after December 15th and you need SRM licenses for that new host, you will need to convert your licenses at a ratio of 5:1 for SRM and then purchase perVM for all your existing protected VMs that are not covered by your converted licenses.  I have a bad feeling this is going to be a wakeup call for some customers.  Another note: there’s no switching back.  Once you go perVM, you cannot go back to perCPU.

I try very hard to look out for my customers and keep them informed.  These licensing changes may benefit some customers wanting to start out with a small number of protected VMs with SRM.  However, most of my SRM customers are like the $45k example shown above.  I don’t see these licensing changes being a benefit to them.  Normally, I don’t discuss licensing in my blog articles.  Some customers have negative attitudes when it comes to licensing.  Some maybe got burned in the past, or just don’t like to talk about spending money.  My goal here is to make sure you can see how these changes can affect you before the impending deadline.  Sometimes I can see a storm brewing from off in the distance.  I just hope that the storm does not cause a disaster, the likes of which even SRM cannot recover from.

I found a few references here and there.  Most customers keep the paging file inside the standard VM disks to avoid making the environment too complex.  I was about to give up and suggest he not separate the paging file, until I came across this discussion in the VMware communities.  I was stunned to see one customer report that they were seeing a reduction of 60% of the replication traffic on certain VMs.  They even saw a 80% reduction of replicated traffic from one of their Citrix servers.  Now I was cooking.  This was amazing and made perfect sense to me how some servers could be more defined by this than others.  I was off to find a documented procedure from VMware to do so.  Unfortunately I came up empty in the Knowledge Base, white papers and best practices.  If you know of such a VMware documented procedure, please post in the comments with a reference link and I will update my article.

After reviewing the communities discussion line-by-line, I came across this NetApp SRM technical paper written by Jeremy Merill and Larry Touchette (whom I was fortunate enough to work with while I was at NetApp).  It contains some great procedures for optimizing NetApp storage and Site Recovery Manager.  Beginning on page 41 however, is a great vendor-agnostic procedure for separating out the Windows Paging file to reduce it’s impact on storage replication.  Jackpot.  Basically there are a few points to consider.  First the windows swap file is configured for a specific drive letter and path.  How do you make sure the recovered machine gets the same drive letter when it comes up in the recovery plan?  The answer is in the procedure.  Jeremy and Larry describe how to configure the source VM with it’s Windows Paging file seperated.  Then they clone the VMDK where the paging file resides and copy it to the destination side.  The reason they do this is because the disk has a signature on it that tells Windows what drive letter it is.  Then they altered the recovery plan for SRM to mount that destination disk to the VM before it powers on.  So that when the recovery VM does come online, it has it’s page file disk as the same letter with the page file intact.  Because the Windows paging file gets wiped on every boot, the data in it is not important, only the location where it’s stored.  They repeat this procedure for every VM in the recovery plan.  I realize that this could be a large undertaking to separate all these page files but the more VMs, the more replication data saved.

I’m very curious if some have tried separating out the page file and what replication improvements you have seen.  Please report those in the comments if you have tried it.  I’d love to hear the results.

There are a few things to think about with regard to licensing  first, vSphere 4.1 now allows for DRS affinity so that VMs only move between certain hosts of a cluster.  I’m still waiting for a definite answer from my VMware friends but that should allow you to protect some VM’s and set their DRS Affinity to only the hosts that you own SRM CPUs for and still keep the full cluster for the unprotected VMs. Previously, VMware would recommend that you create a separate cluster for your “protected” VMs if they were a small subset of the whole.  Now with DRS Affinity, you can dictate that certain “protected” VMs only move between a subset of a cluster.  We’ll still have to wait and see the final ruling from VMware but I’m thinking that would work in the short-term for those in the per-CPU dilemma.

The second feature of the new licensing that I really like is the rolling average of VMs over the last twelve months.  What that translates to is that now I need to buy what my daily average of VMs protected would be over a 12 month period.  If I have certain points of the year where my VM count spikes, this average would be monitored by vCenter and alarm if I am going over my licensing limits.  However, I would only need the average number of protected VMs over the past year.  The system will continue to run after going over your limit but that’s definitely not something I would condone (Famous VMware SE saying: ethics don’t ship in the box people).

The per-vm licenses are sold in blocks of 25 and range from $1,250 to $11,250 depending on the product.  Per-vm licensing will be available for Chargeback, Appspeed, SRM, and, later this year, CapacityIQ.  You can find more information on VMware’s website here.

The last question I had was, “How do I know what my rolling average is for those licenses?”  The good news is that once you enter in a license key, the new license reporting manager in vSphere 4.1 will tell you what your rolling average is year-to-date.  Looks like someone was planning ahead.

You probably noticed by now that there is a limitation in Standard and Enterprise editions of vSphere to a maximum of 6-cores per CPU.  The Advanced and Enterprise-Plus editions of vSphere have a licensed limit of 12-cores per CPU.  Now that Intel’s 8-core CPUs and AMD’s 12-cores are out, what’s next?  Intel and AMD are sure to develop a proc with more than 12 cores (and probably sooner than we all think).  What will happen to VMware’s licensing then?  You have to remember that from a revenue standpoint, when a 24 core proc comes out, customers will be able to run twice as many workloads on that proc (or at least 50% more).  Moore’s Law states that processing performance of CPUs will double every two years.  With the processors doubling in power so quickly, customers are typically not doubling their number of VMs in the same time period.  The result is that customers tend to have a diminishing need to increase their ESX per-CPU licensing.  I know that there are exceptions to this rule, but in the SMB space the majority are not growing that fast (at least not in this economy).  The increase in processor performance actually works against VMware’s current licensing model. It not good to have a direct connection between your main revenue stream and someone else’s CPU release schedule.  What will happen?  What’s the right answer?  Your guess is as good as mine.  Will they go to a per-vm model?  Increase their current limits?  Find some middle-ground between the two?  Will they “grandfather” their customers like AT&T did with the iPad data plans?  Only VMware knows.  My opinion is that this is an issue that has to be dealt with eventually.  Maybe this will be the year, maybe next.

The second licensing dilemma that I run into is in Site Recovery Manager.  It’s no secret that SRM is my favorite non-ESX product from VMware.  As you probably know, SRM is licensed by the physical CPU where the protected virtual machines reside or could reside.  Here’s where that model breaks down:  let’s say I have a smaller customer who’s policy is only to have a DR plan for 5 of their most critical Virtual Machines.  Those five VMs run in a cluster comprise of 5 dual CPU hosts with HA and DRS enabled.  According to the SRM licensing model, I need 10 CPUs of SRM for those 5 VMs.  That does not fly well.  The solution I’ve heard some engineers mention is to create a separate smaller cluster for just the protected VMs.  I’m not fond of that idea because it goes against the consolidation principal.  I’ve never felt that lowering your consolidation ratio was justified because it did not fit a licensing model.

I know there are people much smarter than me at work trying to find a solution to both of these scenarios.  I’m hopeful that they will get resolved in a way that’s fair to both sides.  Maybe this is the year, maybe it is not.  Either way, we’ve made it thru half of 2010, perhaps the answers lie in the last 6 months of the year.

When I suggested CBT to the customer they asked, “Why that one?” and how it worked.  So I explained:  When we replicate from source to target, the first copy is a full copy of the data (the “seed” it is often called).  When we go to replicate the next time, we don’t want to replicate the whole thing again, just what has changed since the last time we replicated (often called a “differential”).  The replication software needs to determine what’s changed.  Prior to ESX 4, there was not a built in method to do this.  The software would have to find another method, such as compare snapshot information and determine which blocks are new.  That uses CPU cycles on the ESX hosts and takes time (differential mode in vReplicator takes  roughly 1 minute per GB of VM data).  On the other hand, CBT is a feature in ESX4 that tracks the block changes that have occurred since a point in time.  It does not keep a copy of the changed data in a separate location, just a log that the blocks in question have changed.  This is a huge help to backup and replication technologies who typically have to determine what has changed on the disks via their own methods.  Now, ESX can tell them directly what has changed and they can get right to copying those changed blocks.  This makes the overall replication and backup jobs much quicker.

Now for a few lessons learned in using it.  First, it requires hardware version 7 VM’s (HW7) and ESX4.  VM’s need to have their VMtools upgraded to the latest version and then you can upgrade the VMs to HW7 when they are powered off via right clicking them (this updates the virtual hardware presented to the VMs and will require another reboot in Windows after powering it on when the OS discovers the new virtual HW and loads the drivers – thanks Microsoft!).  Second, CBT it is not on by default.  It is set per VM and is an advanced option you can set in the VM’s config.  Some software have the capability to change the CBT setting for you.  In our case, vReplicator has this option on the CBT options page.  On that page, it will check every VM that it can see and if they are HW7.  If they are HW7, they will show as supported.  On that screen, you will also see a checkbox for the “enabled” field.  When you click the enabled box on your HW7 VMs, vReplicator makes the change for you in the VM’s configuration.  However, as mentioned earlier, you must completely power down that VM and power it back on.  The reason for this is that, to start using it, ESX needs to create the tracking log for each disk (the log is about .5MB for ever GB of VMDK or Virtual Mapped RDM and it’s stored with the VM) and ESX only does this setup process at VM boot time.  So make note, a restart won’t work.  It has to be a VM power down and VM power back on.  There is a great article that taught me a few things on CBT by Eric Siebert that goes into a little more technical detail and you can find it here.

Once we got this process completed, my customer’s replication jobs ran MUCH faster.  The data being copied from the source to the target was the same, but the time it took vReplicator to determine what to replicate went from minutes to seconds.  Great news too was that we were able to change the replication method on the fly (from Differential to CBT, if you’re using hybrid, I think you need to re-seed).

My final advice, is make sure you understand if your backup/replication software can use CBT and what you need to enable it.  It does take a bit of work to upgrade the tools and virtual hardware (use Update Manager!).  However it’s well worth it in the long run.

Dell EqualLogics, Version 1.0.2, Released 01/20/2010

EMC Celerra, Version 4.0.17, Released 01/29/2010

Fujitsu ETERNUS SF AdvancedCopy Manager, Version 1.3| Released 01/29/2010

IBM DS4000/5000, Version 01.01.35.05, Released 01/15/2010

IBM N-series SAN Adapter, Version 1.4.2, Released 01/07/2010

LSI, Version 1.01.30.05, Released 01/21/2010

You can find the updated SRAs on the SRM download site here.  As always, please check to make sure these updates are necessary for your environment.  I would have included the release notes but unfortunately the vendors are not keep track of them.  Upgrade at your own risk, and if you do, please test your recovery plans out fully with the new adapters.

This release of Site Recovery Manager introduces several new features:

• Full compatibility with vCenter 4.
• Full support for NFS-based arrays.
• Support for shared recovery sites.
  Enables many-to-one pairings of protected sites with a recovery site. For more information, see the technical note Installing, Configuring, and Using Shared Recovery Site Support, which is available at http://www.vmware.com/support/pubs/srm_pubs.html.
• Resilience in the face of vCenter unavailability during a test recovery.
  Placeholder virtual machines can be quickly repaired after the protected site vCenter becomes available again.
• New repair-mode installation features.
  You can run the SRM installer in repair mode if you need to change configuration parameters such as vCenter credentials, database connection information or credentials, and certificate details.
• Graphical interface to advanced settings.
  Eliminates most requirements to edit the XML configuration file
• Support for DB2 as an SRM database server.
• New licensing options.
• Improved scalability.
  A single protection group can now include up to 1000 virtual machines.
• Full Compatibility With DPM (Distributed Power Management)
  SRM recovery plans can now power-on or power-off a host that is in standby mode.
• New Option to dr-ip-customizer Utility
  The dr-ip-customizer utility now logs less verbose diagnostic output by default. To force dr-ip-customizer to log the same level of diagnostic output that it produced in earlier releases, use the -verbose option.
• Change in Certificate Validation
  When you select certificate authentication, the SRM installation validates the certificate you supply before continuing. Certificates signed with an MD5 key are no longer allowed.
• Support for Protecting Fault-Tolerant Virtual Machines.
  SRM can now protect virtual machines that have been configured for fault-tolerant operation. When recovered, these virtual machines lose their fault tolerance, and must be manually reconfigured after recovery to restore fault tolerance.
• Improved context-sensitive Help.
• PDF documents available on release media
  Current versions of the PDF documents for this release are available in the docs folder at the root of the SRM 4.0 CD. Updated versions of these documents may be available at http://www.vmware.com/support/pubs/srm_pubs.html.

The first is wondering how an admin can do more advanced things with the View Manager Server.  For instance: assign a default desktop out of a pool to a specific user or  listing orphaned desktops (users that no longer exist or have changed permissions and no longer have access to a desktop in a pool but still have one assigned to them) or cleaning up after removing a secondary View Manager server.  All of these items can be performed by a little-known command line utility included in View called vdmadmin.exe. vdmadmin.exe can do all of the things mentioned.  The tool is installed by default with view in the  C:\Program Files\VMware\VMware View\Server\bin directory.  You can read all of the details about the tool and all of the command options here .  "Why is this a command-line tool?" you ask.  When features are requested for the GUI, a programmer has to create and test the GUI options which takes a lot of time.  The product manager has to decide what features will make in into the released product and still keep it on time for release.  Sometime features or controls don’t make it but are still important.  A developer can write a command line executable and they are much easier to test as the command line either works or it does not.  The Quality Assurance process is much easier for command line utilities.

Another tool that’s good to know is sviconfig.exe.  It’s located on the vCenter server where you install composer in the C:\Program Files\VMware\VMware View Composer directory.  This tool allows you to unlock protected entities in vCenter.  For instance, if a user checks out a VM offline, it gets protected in vCenter so that an admin cannot accidentally delete it or power it on and make changes.  If the admin needs to make changes to it for some reason they can use the sviconfig tool to unlock that VM.

There’s also a few other topics that come up frequently.  Here are a few:

Can you protect View Desktops with Site Recovery Manager? Unfortunately, SRM is not "View aware" as yet.  The work is underway however.  Tommy Walker from VMware (one of the best @ VMware) has written a blueprint with EMC on how to accomplish this task (although experimental at this point).  It’s pretty interesting reading and I’m very hopeful that we’ll see native integration coming.  You can read the very detailed blueprint here (registration required).

What features do I get with thin client "x"? With the different number of options available for View Thin Clients there’s also a number of different thin client OS options.  Here is a great matrix of what features you get with each View client that is available.  Good information to know when picking out thin clients

How can I make location-aware desktops? This is a common question.  How can I make a specific thin client map a specific printer, etc based on the thin client location?  The answer: Client Information Variables.  Here’s a nice writeup on some basic scripting that can determine the variables and make appropriate decisions based on their values.

Can I use group policy to control the client or desktop agent? You bet.  You can find the administrative templates for group policy in the C:\Program Files\VMware\View Manager\Server\Extras\GroupPolicyFiles directory.  If you’re not too sure about using adm files, here’s a kb article from Microsoft on how to use and manage them.  There are 4 included with View: vdm-agent.adm to control the agent in the guest OS, vdm_client.adm to control the properties of the View client, vdm_server.adm to control the connection broker and vdm_common.adm for common View components across all of View.  A very detailed list of the options of each can be found in the View admin guide starting on page 176.

This release is all bug fixes, here’s the list from the release notes:

The following issues have been resolved since the last release of Data Recovery. For a full list of known existing issues, see VMware Data Recovery 1.0 Release Notes. The list of resolved issues below pertains to this release of Data Recovery only.

• Large Temporary Files Removed as ExpectedData Recovery modifies virtual machines’ vmdk files’ settings so a snapshot can be created for backup purposes. In the past, after the backup has been created, the vmdk file’s settings was sometimes left configured for snapshots even after the backup was complete. This led to these virtual machines being left in snapshot mode while accumulating snapshots that were undetected by vSphere Client. This process has been redesigned so that these temporary files are no longer be left behind. In previous versions of Data Recovery, this issue can be resolved by following the process described in the knowledge base article titled “Delete ddb.delete entries and snapshots left behind by Vmware Data Recovery”.
• Backups Can Be Completed While Integrity Checks Are RunningData Recovery can complete backup operations at the same time that an integrity check is running. In the past, when an integrity check was running, backups could not be completed.
• Improved Integrity Check Backup SpeedIntegrity check has been optimized for faster performance. In the past, comparable integrity checks took longer to complete.
• Improved VMotion Licensing SupportVirtual machines can be moved between hosts using VMotion without producing licensing issues. In the past, if a virtual machine was moved between hosts using VMotion, licensing checks sometimes produced errors.
• Reduced Data Recovery Backup Appliance Shutdown TimeThe Data Recovery Backup appliance now shuts down more quickly than it did before. In the past, the appliance often took 15 minutes to shutdown.
• Improved Support for Different Time ZonesIn the past, Data Recovery did not consistently handle time zones with positive offsets relative to GMT. For example, Data Recovery could encounter issues with data associated with the Paris time zone, which has an offset of +1, whereas data associated with the New York time zone, which has an offset of -5 was handled as expected. These issues no longer occur.
• Data Recovery Supported with Essentials Plus LicensesData Recovery is included in Essentials Plus licenses. In the past, using Data Recovery with Essentials Plus licenses failed. Backup jobs created with Essentials Plus licenses failed with the error, License not available to perform operation. Feature hotplug not licensed....
• Integrity Check Optimized to Run During Idle TimesBefore running regularly scheduled integrity checks, the Backup Appliance determines if the current time is during a backup window. If the current time is not during a backup window, the integrity check runs. If the current time is during a backup window, the backup appliance checks the backup schedule to determine if there will be a time in the next 24 hours that will not be during a backup window. If there is a time in the next 24 hours that is not during a backup window, the Backup Appliance waits for that time. If there is no time that is not during a backup window in the next 24 hours, the Backup Appliance completes the integrity check.

What does Fault Tolerance do to prevent a split brain if both Primary and Secondary VMs become isolated?

Fault Tolerance (FT) uses an on-disk generation number file.  When FT is enabled the primary VM creates a file on shared storage called generation.N where N is a counter number.  The secondary VM is started and when it connects to the primary, the primary tells the secondary what the generation number is.  Once the Primary or secondary detects that there is a failure in the other half of the VM pair, it will try to rename the generation.N file to generation.N+1.  If the rename succeeds, the VM takes over as being the Primary (or remains the primary if it already was) and takes corrective action to rebuild a secondary and become protected again.  If the rename of the generation.N file fails, that means that the other VM in the pair already renamed the file and took over and the current VM shuts down.

There you have it, the disk subsystem prevents both VM’s from becoming the primary at the same time and creating a split brain.