Compartir a través de

Using virtual machines for testing

  • Artículo

Using virtual machines for software development, software testing, and patch testing is really catching on at Microsoft – and for good reason:

  • Hardware goes farther: Using virtual machines instead of physical hardware allows you to do more testing with fewer resources. Note that this isn’t a universal panacea because some testing scenarios must be performed on physical hardware.
  • Test scenarios are quick to deploy: If you create a library of .iso images and/or .vhd files to use as base configurations, virtual machines are quick to deploy. Note that you need to run SysPrep on the operating systems that you want to clone so that the guest operating systems receive a unique GUID and MAC address when they start up. Otherwise, you’ll end up with conflicts.
  • Virtual machine memory state can be retained when turned off: By saving its state, you can “stop” a virtual machine and reclaim the CPU and memory resources it was using on the host, while preserving your test scenario. You can then quickly restore the virtual machine from its saved state when you need it again, and continue your test. Note that disk space is required to store the virtual machine’s memory contents. Also, you can’t transfer a virtual machine in a saved state between two computers that have different CPU architectures, such as Pentium and AMD. To transfer the virtual machine in this scenario, you have to restore it from the saved state and then shut it down.
  • It’s easy to roll back changes: Using undo disks, you can create a complete environment and then quickly roll back any changes you make to it. Your options are to keep your changes, commit the changes back to the parent disk, or discard your changes. Note that it isn’t a good idea to use undo disks with domain controllers because this rolls them back in time :( - not to mention that it isn’t supported by Microsoft.
  • You can create multiple configurations with a single base image: You can configure your base image and then create differencing disks that use it as a parent. On the differencing disks, you can install additional software, upgrade the operating system, install patches, and so forth, without affecting the base image. You can also chain differencing disks to set up complex scenarios, for example Windows Server 2003 (base), Windows Server 2003 SomePatch 1 (differencing disk), and Windows Server 2003 SomePatch 2 (second-level differencing disk). As appropriate, you can then merge the differencing disks either back into the parent disk or into a new .vhd. Note that when you use differencing disks, it’s VERY important to mark the parent disk as read-only. If you don’t and anyone makes a change to it, all of the child disks become invalid, and you have to start over. Also remember that if you want to clone a disk, you need to run SysPrep on it first.
  • You can configure named pipes for your virtual machine COM ports for use with debugging tools.

Here are some tips for testers and developers:

  • Always install Virtual Machine Additions. This is a basic step for every virtual machine deployment, and not just for testing, but I bring it up because it’s so easy to forget.
  • Patch your virtual machines. Virtual machines are just like real machines and will catch viruses. Treat all virtual machines as separate computers for security and patches. Our Virtual Server test team uses the following approaches for patching their virtual machines: Load the patch management system on the host and have it patch the virtual machines, load the patch management system on the virtual machines and dual home them on public and isolated segments, or use Internet Connection Sharing (ICS) to create a virtual Network Address Translation (NAT) environment with Loopback adapter, and have the virtual machines patch themselves.
  • Use SysPrep on guest operating systems you want to clone. For more information, see my article at https://blogs.msdn.com/megand/articles/357570.aspx.
  • Use the COM API to automate your test environment deployment, as described in this MSDN article by Ben Waldron: https://msdn.microsoft.com/msdnmag/issues/04/08/VirtualServer2005/.
  • Use at least two network adapters: one for the host and one dedicated to the virtual machines for public network traffic. Add more network cards to support more network traffic.
    Use Loopback adapter to isolate virtual machine traffic from the host or create isolated subnets. Use Windows Server 2003’s Routing and Remote Access Service (RRAS) in a virtual machine for routing between virtual networks.
  • For some basic background on using virtual machines for testing, read this article about testing with Virtual PC: https://www.windowsecurity.com/articles/Microsoft-Virtual-PC.html.
  • Read the documentation. :)  It has loads of helpful stuff in it.

Comments

  • Anonymous
    January 28, 2005
    There are also products, like Surgient's Virtual QA Management System, that sit on top of MS Virtual Server and provide these sorts of capabilities as part of a complete lab automation solution. Great for teams and testing enterprise systems.
  • Anonymous
    January 28, 2005
    Thanks for the tip, Anonymous!