8. Virtual PC - Best Practices
Filed By: Robert Moir
8. Virtual PC - Best Practices
This document is intended to discuss several "best practice" habits to use when deploying Virtual PC 2004 into production environments.
Before you begin.
Prior to deploying Virtual PC, you should plan out your needs based on what sort of deployment you are doing. Obviously, there is no need to produce a detailed 30 page project plan for installing Virtual PC on one machine in accounts so "Linda from accounts" can use that dodgy old bank software that the bank refuse to upgrade, but even for "minor" installations like this, a bit of time spent asking yourself a few questions now can save a serious migraine later.
What type of deployment are you doing?
There are a few basic scenarios which most people follow when deploying Virtual PC, I've outlined a few below. Thinking about what kind of deployment you are doing should help you answer the other questions asked in this section.
- Supporting legacy applications on user desktops.
- Allowing IT support staff to run several basic "images" that are in use around your company, in order to see what their users see in support calls.
- IT Support laboratory work - using Virtual PC to reduce the hardware costs of running a test lab for various network scenarios.
- For example, running a trial on a new patch for your current systems, or even trials of entirely new systems.
- Testing upgrade/migration scenarios.
- A "secure sandbox" for testing untrusted apps or code would be another, more specialised, example of this sort of use.
- Training laboratory - using Virtual PC to provide a training environment for a class you are running.
- For example, teaching IT Support personnel about networking in an environment where their mistakes can't impact the real network.
- Allowing students in a college or school to run applications that would normally be regarded as "untrustworthy" to be ran in your real network environment.
- Programmer/development tool. Virtual PC allows programmers to have various test environments on their desktop from just one physical computer. This allows them to test apps on a variety of platforms without too much bother, and of course, to easily and cheaply have their own client AND server when working on client/server apps.
What questions should you be asking yourself?
Once you know how you intend to use Virtual PC, you need to consider the following questions, plus of course any other issues that are specific to your network.
Will the virtual computer be visible on your "Main" network?
If so, you need to consider naming schemes for your virtual machines, security for your virtual machines, and how you wish to provide OS and application packages and updates to the virtual machines.
If you plan to join virtual machines to your domain, they will function like normal domain clients, which may include applying GPOs that lock things down in a way you don't want for your virtual machine if it is running Windows. Consider creating a seperate OU for your virtual machines so you can have better control over which GPOs are applied to Windows virtual machines.
Patching apps/OS and updating antivirus software can be problematic for virtual machines. Often, administrators push updates out during the nighttime, instructing users to leave their PCs on. As virtual machines can use a lot of processor power, they are typically switched off when not in use, which means they may never receive AV and operating system updates. It would be a nightmare to track down a worm running on a virtual machine that is only switched on occasionally.
Remember that virtual machines need to be treated the same as physical machines when it comes to security. If someone needs to run a legacy app as a local administrator in order for the legacy app to work properly, the security implications of this need to be evaluated.
It can be helpful to know which systems on a network are virtual ones, and it is certainly helpful to make sure the names given to virtual machines never clash with the names of other machines on your network.
As for naming schemes, Virtual PC newsgroup regular Scott Baker posted these comments to a question about this in the VPC newsgroups:
"To make it easier, you might need to establish policy about system naming rather than trying to rely on remote scans, etc. For example, you could set the policy to base all of the VM names off of the Host name, with an extension:
A very simplistic example, but you get the idea."
I actually do something very similar to Scott's example at work, my only change is as part of the overall naming convention there, we use a code that indicates what OS is running on the machine, plus the asset tag number, and for virtual machines, I add "v1", "v2" etc at the end of the name.
How will you deploy your virtual PCs?
For most scenarios, this is simple to do. You can simply install virtual PC as a normal Windows app, and then install your guest OS by hand.
If you need to create multiple virtual machines, either on one or many host PCs then most other installation techniques work also, such as RIS, Ghost, etc. However, you need to remember that the virtual machines will have different hardware from your normal physical PCs.
If the Virtual machines are all duplicates then you can of course just set up your OS and apps once, and then copy the .vhd file as many times as you need. This works well for seperate "stand-alone" uses, but if you need to network the machines together, you need to remember to change the machine names and in some cases for Windows, the machine SIDs also need changing.
How will you back-up the data in your Virtual PCs?
You can't backup content in Virtual PCs while the Virtual PC is running. So what will you do instead? If the Virtual Machine will be running continously, then I would suggest using the native backup routine that comes with the guest machine.
In either case, you need to test your backup and restore routine for machines that are used for working with legacy apps or as development environments. Resolving this should be a blocking issue on any deployment.
