Recently I was reading Seth Godin’s blog, which has nothing to do with virtualization, but everything to do about the mindset of a consumer.  He points out something very basic in his entry, that Microsoft needs to address in Hyper-V and other virtualization management apps.  I won’t reiterate his whole entry but the last two lines point to what Microsoft really needs provide to truly make market gains.

“The chances that you can top a trusted provider on the very thing the provider is trusted for are slim indeed.”

“Instead, you gain converts by winning at something the existing provider didn't think was so important. “

To some degree, the standalone Hyper-V Server R2 gives the consumer something new,  A free hypervisor with capabilities which its main competitor does not provide in its free offering i.e. Live Migration of VMs.  Where as this is a valid product differentiation, it is not a feature differentiation.  This has been tried in the past, offering something free that used to be a licensing cost.  This usually does not have staying power.  At best this is just a momentary advantage that competitors soon follow i.e. Virtual Server 2005, VMware Server, Hyper-V, XenServer

So much of Microsoft’s server virtualization strategy has been to compare itself to VMware on a feature by feature basis.  To some degree I think this was important. If they came out with a product that diverged too much from established definition of server virtualization, no one would take them seriously in adopting the product.  Now however, since the feature set between the products is converging, where do they go next.  VMware has grand plans to encompass the total datacenter.  Whether this plan succeeds or not, is still to be debated, but it is a unique product offering.  What will Microsoft do?  I see them making inroads into the small to medium businesses with the current product set, but for those that are enterprise customers, will there be any real innovation?

While writing an article for SearchServerVirtualiztaion on snapshots one of the editors posed the question. What does AVHD stand for?  Honestly, I didn’t know.  I knew a VHD stands for “Virtual Hard Disk”, but what about the “A?”  The customary search through popular search engines came up mostly empty except for one.  Actually four, but the all had a variation of the same title (search results) so I will call them one for the sake of argument.  Anyway, it wasn’t something that was easily found.  There were plenty of references of .AVHD files and what they are, snapshot differencing disks, but very limited reference to what the “A” represents.  So what did this one search reference say the “A” stood for?  “Automatic Virtual Hard Disk.”  Seems to fit, but I was still skeptical given the limited results to back it up.  This led me to pose the question to others in the Virtualization field.  Here is what they came up with:

Ben Armstrong (Virtual PC Guy) - “We have never (AFAIK) actually documented what the "A" is for.  But it is "automatic". “

John Howard - Hyper-V and virtualization blog  “Rob - yes, the A stands for Automatic. Under the covers, an AVHD is simply a differencing VHD with a different extension. We use the different extension to make it more obvious that users shouldn't be manipulating VHDs directly, rather use the snapshot capability directly.”

Mike Briggs - Senior Support Escalation Engineer (Microsoft System Center Support) “Although I haven't seen any official documentation anywhere that spells it out clearly, we have always referred to it as "automatic" which I think stems from Rob Larson's Resource Kit for Hyper-V. (Isbn# 978-0-7356-2517-4)”

A little more clarity on the subject.  Not sure if this makes you or me any smarter, but maybe there will be at least one more search result in the list.

I have been working with Microsoft over the past year in the Hyper-V Rapid Deployment Program.  Here is our story.  Works great, saves money, space and energy.  There are lots of good case studies out there.  If you get a chance, take a look at a few.

As I mentioned in a previous post, I have been involved with Microsoft with the Rapid Deployment Program for Hyper-V.  It has been a great way to get immersed in the product with full premier support and the ability to give feedback directly to Microsoft.  Along with those benefits, I have had the aid of John Wilson, from Microsoft Consulting Services, on-site one day a week to help guide and provide an inside track to configuration and troubleshooting. 

As a result of my involvement, the organization where I work has been mentioned in one of the growing number of case studies for Hyper-V.  Take a look.

Dartmouth-Hitchcock Medical Center - Solution Brief

All Hyper-V Case Studies

-Rob

I have been working with Volume GUIDs more and more in our Hyper-V implementation and there has been a little bit of a learning curve in viewing, modifying, deleting etc... the files that now live on this volume without a drive letter.  I haven't seen much out there on how to manage Volume GUIDs so I thought it would be a good topic for the blog. 

I have to plug Adam Fazio for leading to some of the info I have gained on this topic.

Like a normal volume, with a drive letter, there are 2 ways to view, modify, copy etc... files that reside therein. Explore in the GUI and Command line access.

Explorer View:  Just paste the Volume GUID in a RUN command.  This will give you the common Explorer view of your files that reside on the volume.

Command Line: dir \\?\Volume\\   i.e. dir \\?\Volume{fc247e42-0a5e-11dd-94db-001b785788b0}\\  The key to this one is to make sure you are using the second backslash at the end of the Volume GUID if you want to get to the root of the volume.  If you want to go to a known subfolder however all you need to do is \\?\Volume{fc247e42-0a5e-11dd-94db-001b785788b0}\FOLDERNAME.  No second backslash needed.

So this is a good step to being able to manage these types of volumes, but how do you get the Volume GUIDs.  In a webcast from Adam Fazio today he presented a Powershell script that displays all the Volume GUIDs on a local or remote server. [For remote, change localhost to a computer name or computer names. Separated by a comma.]

Get-WmiObject -class Win32_Volume -computername localhost | where-object {$_.name -like "\\?\*"} | select-object label, name, capacity, freespace | format-list

I have created a command file that runs this as a powershell script with a pause at the end to allow me to copy off the Volume GUID I am looking for.

NOTE:  Even though you can output all the Volume GUIDs of a remote server, at this time you cannot access the Volume  remotely. The above ways to access your Volume GUIDs can only be done from the localhost where they reside.

Hope this helps you out.

-Rob

I have been working with Hyper-V for a while and have had this problem with mounting ISO files that sit on a common file share within our organization.  The problem was when I tried to mount them from my remote Hyper-V management console I would get the error below.  If I mounted it from the Hyper-V host Hyper-V management console everything worked as expected.

This stumped me for a while, but then I got to thinking.  Where had I seen this before....  Virtual Server 2005.  Constrained delegation of authority settings on the Virtual Host objects was necessary there in order to both mount remove ISO images and in order to manage the virtual hosts from a common management web page.  So I made similar modifications to my Hyper-V host objects and now all seems to be working correctly.  Below are the steps I took to make mounting ISO images with my remote Hyper-V management console, work like a charm

Open Active Directory Users and Computers, Right-Click the Hyper-V host server object and select properties.  Then click on the Delegation tab. 

Select "Trust this computer for delegation to specified services only" and "Use any authentication protocol."  Then click "Add"  to select the service necessary to pass credentials to the remote file server where your ISOs are located.

Click on "Users or Computers"

Enter the name of the remote resource you need to pass credentials to through the Hyper-V Host and click OK. (i.e. File Server that houses your ISO images)

Select CIFS as the service type and click OK twice.

The refresh on this procedure can take a few minutes to propagate to the Hyper-V host object.  Once this is completed you will be able to successfully mount an ISO from your remote Hyper-V management console.  I suspect that this type of information will be in the final Hyper-V documentation, but as of yet, I have not seen any public documentation outlining this.  If I missed anything or you have any questions, feel free to comment or send an email along. 

The organization I belong to is part of the Hyper-V rapid deployment program which is a program run by Microsoft to get organizations to deploy production virtual servers on early RC and RTM code so that when the code is deployed to the rest of the world, they can note that they have X number of organizations already running it in production.  If you have been to any release event, these are the early adopter stories.  It also comes with great support from Microsoft and Partners who really want the early implementations succeed.  If you ever get the chance to be part of a TAP or RDP, I would recommend it.

So back to the backup script.  Being part of the rapid deployment program, and the desire to test out Hyper-V with production based virtual servers, we needed a way to protect the data that is the servers incase of problems.  Of course we could have just put a backup agent on the child servers and completed file based backups, but that can be a scheduling and resource nightmare once you get a large number of child servers on a particular parent server.  It also did not meet our standard of how we backup our servers in our Virtual Server 2005 R2 environments.  So, to mimic the success we had with backing up our Virtual Server 2005 R2 environment using the VShadow SDK, we looked for a similar solution. 

What we discovered right off the bat is, the VShadow SDK does not work on Windows 2008.  After a little reading of Windows 2008 documentation and a some Googling we came to realization that there was  a new and improved utility called DiskShadow.  What we came up with is a fairly simple compilation of a Diskshadow script and CMD files that takes live snapshots (using the VSWriter) of child servers, mounts those snapshots and then uses rob0copy to copy the files to an alternate location for backups to tape that happen during the daytime hours. 

Below are the scripts that consist of the backup procedures as it stands today.  This has already gone through many different derivatives, and I suspect this will evolve over time or maybe as others add their input.   Randy Pausch makes a good point about feedback from your peers and the inability to grow without it.  Please feel free to leave feedback.

Take note of line wraps.

VSBACKUP.CMD

*****************************************

REM Date Formatting
FOR /F "TOKENS=1* DELIMS= " %%A IN ('echo %date%') DO SET CDATE=%%B
FOR /F "TOKENS=1,2 eol=/ DELIMS=/ " %%A IN ('echo %date%') DO SET mm=%%B
FOR /F "TOKENS=1,2 DELIMS=/ eol=/" %%A IN ('echo %CDATE%') DO SET dd=%%B
FOR /F "TOKENS=2,3 DELIMS=/ eol= " %%A IN ('echo %CDATE%') DO SET yyyy=%%B
SET dateStamp=%mm%%dd%%yyyy%
c:
cd vsbackup
Echo %date% %time% >>c:\vsbackup\logs\%dateStamp%_%computername%_VSBackup.log
REM Execute DiskShadow script
diskshadow /s c:\vsbackup\vsbackup_step.dsh >>c:\vsbackup\logs\%dateStamp%_%computername%_VSBackup.log
Echo %date% %time% >>c:\vsbackup\logs\%dateStamp%_%computername%_VSBackup.log

VSBACKUP_STEP.DSH (coordinates backup proceedure)

*****************************************

#Diskshadow script file

#Maintenance task to clear all previous Volume Shadow Copies
DELETE SHADOWS ALL

#Allow for shadow copies to be persist across program exit, reset or reboot.
SET CONTEXT PERSISTENT

#Cab location for process
SET METADATA c:\vsbackup\cab\Backup.cab

#Verbose on because knowing what is going on is good.
SET VERBOSE ON

#Start Backup process
BEGIN BACKUP

#Alias volumes for easier use in process. 
#Both Drive letters and volume GUIDs are used.
#Volume GUIDs are used for those virtual guests
# on volumes with out a drive letter.
ADD VOLUME D: ALIAS G1
ADD VOLUME \\?\Volume{ac9658ca-fa80-11dc-85fa-001b785788b0}\ ALIAS G2
ADD VOLUME H: ALIAS G3
ADD VOLUME J: ALIAS G4
ADD VOLUME \\?\Volume{6019c063-1540-11dd-b48d-001b785788b1}\ ALIAS G5

#Create Snaps
CREATE

#Maintenance script that deletes previous days file backup from
#secondary backup drives
EXEC c:\vsbackup\backupscript_maint.cmd

#Exposing of shadows and coping to secondary backup drives
#for each volume alias above.
#Using UNEXPOSE as a fallback proceedure incase Volume Shadow
#Copy malfunctions.
EXPOSE %G1% X:
EXEC c:\vsbackup\backupscript_step.cmd
UNEXPOSE X:
EXPOSE %G2% X:
EXEC c:\vsbackup\backupscript_step.cmd
UNEXPOSE X:
EXPOSE %G3% X:
EXEC c:\vsbackup\backupscript_step.cmd
UNEXPOSE X:
EXPOSE %G4% X:
EXEC c:\vsbackup\backupscript_step.cmd
UNEXPOSE X:
EXPOSE %G5% X:
EXEC c:\vsbackup\backupscript_step.cmd
UNEXPOSE X:

END BACKUP
#End of script

BACKUPSCRIPT_MAINT.CMD

*****************************************

FOR /F "TOKENS=1* DELIMS= " %%A IN ('echo %date%') DO SET CDATE=%%B
FOR /F "TOKENS=1,2 eol=/ DELIMS=/ " %%A IN ('echo %date%') DO SET mm=%%B
FOR /F "TOKENS=1,2 DELIMS=/ eol=/" %%A IN ('echo %CDATE%') DO SET dd=%%B
FOR /F "TOKENS=2,3 DELIMS=/ eol= " %%A IN ('echo %CDATE%') DO SET yyyy=%%B
SET dateStamp=%mm%%dd%%yyyy%
Echo %date% %time% >> c:\vsbackup\logs\%dateStamp%_%computername%_maint.log
REM Delete directory with previous nights backup.
rd /s /q f:\%computername%
Echo %date% %time% >> c:\vsbackup\logs\%dateStamp%_%computername%_maint.log

BACKUPSCRIPT_STEP.CMD

******************************************

REM Reusable file copy proceedure for mounted shadows.

FOR /F "TOKENS=1* DELIMS= " %%A IN ('echo %date%') DO SET CDATE=%%B
FOR /F "TOKENS=1,2 eol=/ DELIMS=/ " %%A IN ('echo %date%') DO SET mm=%%B
FOR /F "TOKENS=1,2 DELIMS=/ eol=/" %%A IN ('echo %CDATE%') DO SET dd=%%B
FOR /F "TOKENS=2,3 DELIMS=/ eol= " %%A IN ('echo %CDATE%') DO SET yyyy=%%B
SET dateStamp=%mm%%dd%%yyyy%
Echo %date% %time% >> c:\vsbackup\logs\%dateStamp%_%computername%_xcopy.log

REM Check to see if backup drive and directory exist.
if not exist f:\%computername% md f:\%computername%

REM Copy mounted volume data to secondary backup drives.
REM I used Robocopy for its logging and retry capabilities.
REM Any Copy proceedure would work
REM Note the exclusions that could cause problems with coping files.
robocopy X:\ f:\%computername%\ /E /V /NP /LOG+:"c:\vsbackup\logs\%dateStamp%_%computername%_xcopy.log" /ZB /R:2 /W:30 /XJD /XJF /XD $RECYCLE.BIN SYSTEM* MP* /XA:SHO
Echo %date% %time% >> c:\vsbackup\logs\%dateStamp%_%computername%_xcopy.log

So, here is the code we are using to backup the servers.  In the next post, I will go through the scripts in more detail.  Until then, send your feedback.

Rob