The VMguy

I was going over the KB digest this morning and saw a few KB articles that hit home with a couple issues that customers have been asking me about regarding View.

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. Read the rest of this entry »

I’m a huge fan of Data Recovery.  It’s very bare-bones but it does what it sets out to do.  I’m hoping to have a review of Data Recovery completed later this week.  In the mean time, v1.0.1 was released Friday (the releases keep on rolling).  You can download the new version here.

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. Read the rest of this entry »

I’m training all of my partner engineers this week and they always ask the toughest technical questions.  Thanks to Scott Phillips for asking me this one:

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.

One of my favorite things in talking to people is when they tell me how well the software I teach them about works.  Even better is when someone will take the time to blog about their experiences.  I have had a few customers become early adopters of Site Recovery Manager.  One of the most memorable was a customer (let’s call him Virtual_JTW) whom I worked with in September.  On a Friday afternoon we ran thru configuring and setting up SRM in his environment.  We worked thru the configuration and integration with his Celerra storage.  In the end, we passed with flying colors and his Disaster Recovery test was 100% successful.  It was fun and exciting for me to watch Virtual_JTW’s reaction to the success of the test.  He felt so impressed by the results and his subsequent demonstration for his Disaster Recovery team, he felt the need to blog on the whole experience.  You can read his account of what happened as well as the test results here .