TechEd 2005 is coming right up, from June 5 - 10 in Orlando, FL, US. Register before April 15 to save $300.

The following are some breakout sessions and hands-on labs where you can learn more about using Virtual Server and Virtual PC:

1. Consolidating and Migrating LOB Applications Using Microsoft Virtual Server 2005
2. Developing on Virtual Server 2005
3. Branch Office Infrastructure Solution Using Virtual Server 2005
4. Clustering with Virtual Server 2005
5. Advanced Desktop Testing Scenarios with Virtual PC 2004
6. Virtual PC: Getting Started with Dealer and Manufacturer Sites

In addition, technical experts on Virtual Server and Virtual PC will be available in the cabana and community lounges to answer your questions. For more information and to register, go to: http://www.microsoft.com/events/teched2005/default.mspx. See you in Orlando!

As you may know, Windows Server 2003 SP1 has been released, and a lot of people will be rushing to upgrade their virtual machines. If you're thinking about doing this, though, plan on postponing it for a bit. Virtual Server 2005 was released many months before Windows Server 2003 SP1, and the Virtual Machine Additions are not optimized for it. You may be disapointed in the way your virtual machines run.

But don't despair -- Virtual Server 2005 SP1 will include updated Virtual Machine Additions for Windows Server 2003 SP1 as well as the other new supported host and guest operating systems (see my earlier post on Virtual Server 2005 SP1 features). As soon as it's available, I'll let you know.

** The Beta release of Virtual Server 2005 SP1 is now available, as announced in this post: http://blogs.technet.com/megand/archive/2005/04/20/403960.aspx.**

Note: If you upgrade your host operating system to Windows Server 2003 SP1, you may have trouble accessing the Administration Website. If this happens, you need to configure DCOM as described in this KB article: http://support.microsoft.com/?kbid=891609.

Mikko wants to know about best practices for backing up virtual machines. Well Mikko, according to Jeff Woolsey, a Virtual Server Program Manager, there are two ways to backup a virtual machine. Both have pros and cons, so you'll need to determine which method best suits your business requirements. The first method is the recommended option.

Method 1: Back up each virtual machine from within its guest operating system

The first method is to install backup software in the guest operating system and back up each virtual machine in the same way you would a physical computer. The advantages to this method are:

• The backup can be performed “live” on running virtual machines.
• If your organization has a standard backup process, you can use the existing process. There aren’t two different methods to back up physical versus virtual machines. 

The disadvantages are:

• You need to purchase a backup software license for each virtual machine.
• Backing up the each virtual machine may take longer than backing up all virtual machines from the host operating system.

Method 2: Back up all virtual machines from the host operating system

The second method is to back up the Virtual Server host operating system. You can back up the entire host computer and all virtual machines at once, but this can only be performed when all virtual machines are either stopped or in a saved state. The downside is that this is not a “live” backup. You must shut down or save the virtual machines to perform the backup. Otherwise, the effect on your virtual machines will be like pulling the power code on a physical computer and then making a copy of the hard drive. The hard drive might boot next time, but Checkdisk would certainly need to run, and there will likely be corrupt user data.

Why is this a problem? The issue is that when you back up the host, the files on the disk are backed up, but not the memory in use by the running virtual machines. For example, if you allocated 2 GB RAM to a virtual machine and backed up the host operating system, there is potentially 2 GB of virtual machine data not backed up! To safely back up a virtual machine, the entire state of the virtual machine must be backed up which includes:

• The contents of the virtual machine’s memory (in .vsv files, when the virtual machine's in a saved state)
• The virtual hard disks (in .vhd files)
• The virtual machine configuration (in .vmc files)

You can automate this process. For example, you could write a script to save the state of the virtual machines and back up the host operating system, but such a script is not included with the product. In the Scripts category of this blog (http://blogs.technet.com/megand/articles/category/9995.aspx), you can find a sample script for backing up a virtual machine and restoring it to a different instance of Virtual Server, which you can modify for your own purposes. For additional script samples, go to the Virtual Server script repository (http://www.microsoft.com/technet/scriptcenter/scripts/vs/default.mspx).
 
The advantage to this method is that the backup may be faster.
 
The disadvantages to this method are:

• If not performed properly, it can result in the loss of data.
• The backup is not live. All of the virtual machines need to be saved at some point.
• This backup process is virtual machine-specific, resulting in two backup processes -- one for physical machines and one for virtual machines. 

Notes:  

• If you want to restore a virtual machine saved state (.vsv) file to a different host computer, the new host must have the same CPU type as the original one, such as Intel Pentium or AMD Athelon. It also must be the same generation, such as Pentium IV. In addition, you can't transfer saved state files between Virtual PC and Virtual Server. If the processor types don't match or you want to restore a virtual machine from Virtual Server onto Virtual PC, you'll need to restore the virtual machine from the saved state (assuming it's currently saved) and then shut down the guest operating system before performing the backup and restore operation.

• See the Virtual Server Administrator's Guide for more information about the files and folders to back up and their locations.

You may have noticed that this blog is now published on TechNet rather than MSDN. It has been moved so it will be more discoverable by IT Pro readers. You may also have noticed that there have been a few minor glitches in the transition. The biggest one (aside from losing my "skin," which I'm going to try and recover to replace this one, which I don't like that much) is that none of your comments or my responses to your comments are visible. The good news is that they aren't lost -- they're still in the database, but just aren't making it to my blog. The migration team is working on the issue, and hopefully your comments will be back in view by Monday. In the meantime, keep sending them, but don't expect to see them for a few days.

Thanks for your patience!
Megan