Building a virtual host
We used several steps after installation to prepare virtual guest slots on our Hyper-V and ESX hosts. We then populated them to emulate server migration and consolidation processes. Once either hypervisor is installed, we could generate guest instances that served as holding spots for installable operating system/application instances on physical servers that we wanted to migrate to our host servers.
Both Hyper-V and ESX allowed us to install guest instances without aid of the SC-VMM and VirtualCenter tools, respectively, and then install either a pre-made VM instance, install an operating system from CD/DVD, or install from a network source/share. That said, the added management tools can be helpful in this process if in use, serving as a user interface to the hypervisor in question. Both tools eased common VM instance management tasks, such as duplicating, creating, copying, and allocating and re-allocating resources.
For currently existing operating system/application pairings that need to be migrated to a virtual host, each hypervisor tested has a similar procedure to capture a server instance and import it into a virtual guest slot that we’d prepared.
This process of copying a current physical server to a target server is a process known as cloning. There are two primary physical to virtual (P2V) cloning methods that both hypervisor products support: the ability to migrate from a disk image, and, the ability to clone from a live production server.
Unfortunately, Microsoft's P2V process couldn't be tested because this portion of the beta application crashed despite lots of patching, intricate settings tweaks, and calls to advanced technical support. It’s not ready yet.
VMware's P2V application is an optional extra called VMware Converter, and when we tested it, it worked well in most cases as long as the hard disk controller was supported. It worked best with Windows, where we could produce live clones from Windows XP and Windows Server 2003 images. To cold clone Linux and Windows Server 2008 VMs required some extra setup steps after it was copied.
Images of working virtual machines can then be used as the base of replicas for other VM guests. The images, however, are in known formats and can be mounted as file systems for purpose of manipulation of the content files/folders. Hyper-V uses a cross-Windows file format called VHD,and ESX uses a published system called VMDK.
Some organizations use virtualized images for distribution, and images may need to be customized for purposes of making the image unique (a Windows requirement, generally, for identification), or to load specific software combinations as a payload for a targeted distribution of the virtualized physical hardware instances to other locations.
With both products we found that mounting and editing the images can be simple, but also run the security risks we talk about in detail below.