Hyper-v DOs and DON'Ts - Item 1 - Re-Sid your machine.

We've started utilizing hyper-v for our product system testing. Beforehand the system test environment was composed mostly of around 16 physical machines playing different roles in different topologies. The machines applicative layer was mostly managed by loading up pre built specific role images. Things like different operating systems, different applicative clients (IE6/7/8 Office/2k3/2k7, etc) . Moreover, the  network topology was mostly managed by a VLan switch which was good in the flexibility point of view of moving machines between different networks without plugging out and plugging in different network cables. But once more complicated scenarios were introduced and more people got involved in the system testing effort , it was pretty obvious that the current test lab wouldn’t be able to scale up to the system testing requirements. So after a basic pros and cons analysis and discussion we have decided that we are going to introduce and rely on hyper-v as our virtualization engine but keep the old physical lab as a Plan-B if we would have to prove issues or sightings on a physical environment as well. Around one month down the road, we're very satisfied by the agility the virtual environments is providing us, changing network topologies on the fly , having a library of role specific images and a lot of other time saving advantages that I'll probably share in the future. Having said that , we've collected several good to know DOs and DON'Ts for working with a virtual environment in general and Hyper-V specific.


Overscaling..



So here is sharing the first DOs.
It is very tempting to create basic OS templates , that can be stored in a library and be used as real virtual machines instances. For example, installing a basic winxp on a virtual machine, shutting it off and saving the virtual hard drive to be cloned and insatiate as new virtual machines from that specific winxp library image.

But having multiple machines instantiated from the same installation image might result in a situation where you have different servers but with the same Server Sid (unique id). This might have an impact on all sorts of network aware application who use this unique id to for server identification. we actually saw these issues happening in reality with domain users name resolution.So to the rescue came sysinternal with their little handy tool with a very catchy name called newsid
Basically , it changes all of the current machine's SID with either a random or user supplied SID. You can read more information in the above link.
It also has a quite mode in , where no user interaction is required so it can be perfectly integrated into a "runonce" script that would be ran only once when the image is first instantiated as a live virtual machine.There are lots of ways to implement this solution , here is a very basic one:
Write the following powershell script:

#***********************************************
if(!(test-path "c:/temp/new_sid.txt"))
{
 echo "Running New Sid"
 touch c:/temp/new_sid.txt
 c:/temp/newsid.exe /a
}
#************************************************

You also need to trigger it to be executed once the machine is up , one way to do this is to place a simple batch file in the all users startup folder (in server 2008, open up an administrator console and cd to c:\users\all users\start menu\programs\startup and drop the batch script here)
This simple script just check for a file existence in c:/temp. If it doesn't exist , meaning this is the first time, it creates the file (so it won't run again next time) and runs the newsid application (download from sysinternals into c:/temp , see link above). a restart, unfortunately, is unavoidable. but once restarted it has a new server SID and the virtual machine is ready to start its new life.

There are probably lots of other ways to do this or to improve this specific way , for example , adding a splash screen saying that the server is reconfiguring for the first time , etc. 


Sowing the Sids....

So let's recap on this , when using a virtual machine VHD (hard drive file) as a template, do the following to make sure clones or actually virtual machine generated from this library VHD (hard drive file) do not collide with each other on their SID level.
  • Use a VM to setup your basic OS.
  • download the newsid.exe and drop it on a folder on the VM machine (let’s assume it is c:/temp)
  • Drop the powershell script in the same folder
  • Add a simple batch file that executes the powershell script on startup (something like powershell c:/temp/new_sid.ps1)
  • Shutdown the VM
  • Save the hard disk image file.
  • Test this solution by instantiating a VM from this hard drive image (and make sure that the newsid application runs once and only once)  
      
**Update,  a work colleague  suggested the following trick , which makes it simpler, but might shorthanded when trying to enlarge the feature scope of this solution.
Instead of using a vbs or a powershell script, just add the following reg key to resid the machine on first boot.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /v "Create new SID" /d "c:/temp/newsid.exe /a" /f  - This will execute the new sid app for one time only on first reboot.


 

1 Comment

  • I was looking to literally virtualize my production environment in order to create a Virtual Test Lab environment. My production environment would run as normal, but the virtual environment would be used to test anything before going into production. This way snap-shots would be taken in the virtual lab BEFORE anything was tested, and if the test blew the VLab up, we could roll back and try again with almost no down time. I have read the VSMT White paper, and have my '08 Hyper-V server running. I was hoping I could get some advice from someone who has already gone through this. Thanks in advance!

Comments have been disabled for this content.