Although some management components of SCVMM have already been discussed, SCVMM
deployment tools are of special interest. SCVMM allows OS images, hardware profiles, and software profiles to be stored in its library for easy deployment. These profiles and images make VM cloning and template deployment very efficient.
VM cloning with SCVMM
Creating a VM clone through the SCVMM wizard is efficient and easy. If moving or duplicating a VM to an entirely different environment, creating a clone first ensures that if the export fails due to network or other issues, the original is still available and unchanged. Also, VMs or clones can be moved to the SCVMM library for later deployment. This is an ideal method for duplicating existing VMs.
XML unattend files can be used to further automate configuration. Using SCVMM templates to deploy new VMs is perhaps the most effective method of deployment because with profiles, unattend files, and existing images, new VMs can be named, automatically added to a domain, and have applications and updates preinstalled. Many other settings can also be configured, reducing an administrator’s post-installation task list.
Figure 19. SCVMM Library with templates, profiles, and images for deployment
Creating a VM template in SCVMM does not require running Sysprep first as with other deployment
tools because Sysprep is part of the template creation process. Be aware, however, that creating a
template consumes the source VM, so it might be beneficial to first create a clone of the source VM, and then use the clone to create a new template.
Best Practice
Use XML unattend files, hardware and operating system profiles, and SCVMM templates to easily deploy highly configurable VMs. Because creating a VM template consumes the source VM, use SCVMM to create a VM clone of the desired VM, and then create the template from that VM clone.
Physical-to-virtual (P2V) deployment through SCVMM
Server consolidation is one of the greatest reasons for implementing a virtualized environment. However, creating new VMs and changing them to function as the physical servers did can be a slow process. To simplify the process, SCVMM has a feature to convert a physical server to a VM. The Convert Physical Server (P2V) Wizard scans the specified server and presents valuable information about the server as shown in Figure 20.
Figure 20. SCVMM convert physical to virtual wizard—system information scan
When performing a P2V conversion, it is possible to select some or all (default) of the desired disks (both local and external) to convert to VHDs for the new VM. However, all selected disks are converted to VHDs on one (specified) volume. If any of the new VM’s disks are intended to be pass- through disks or if they should reside on separate volumes or disks, this must be done manually. To avoid consuming excessive network bandwidth and time, instead of converting all physical disks to VHDs, if possible (for example, if storage is on a SAN), unpresent the disks from the physical host, and re-present them to the new VM after it has been created. Although this cannot be done for the root partition, which must be converted if using the P2V conversion wizard, this might result in additional time and bandwidth savings.
Best Practice
To save time and consume less bandwidth, when performing a physical-to- virtual conversion, convert only the root partition and disks that cannot be moved to connect to the Hyper-V host. For all other (nonroot) disks, simply unpresent them from the physical server, re-present them to the Hyper-V host, and attach them to the new VM.
Although the default VHD type is dynamic, it is possible to choose a fixed VHD for a P2V conversion. A previously discussed performance best practice is to use fixed rather than dynamic VHDs. Creating a fixed VHD, however, matches the specified size of the source disk, including unused capacity as shown in Figure 21. In environments with large disk drives or slow networks, this conversion might take a significant amount of time and bandwidth. Using the dynamic VHD copies only the necessary bits, resulting in faster conversions, and is therefore recommended when source disks are large or the network is not sufficient. If fixed VHDs are desired and performance is a concern, then after
converting large disks to dynamic VHDs, convert the dynamic VHDs to fixed within Hyper-V and expand the VHDs if necessary.
Best Practice
To avoid copying large quantities of unused disk capacity across the network, for all required P2V disk conversions, convert to dynamically expanding VHDs instead of fixed VHDs. If necessary, after the conversion, convert the dynamically expanding VHDs to fixed VHDs and expand them for improved performance.
Summary
This white paper details best practices and storage considerations for a Hyper-V environment with the EVA4400. The primary take-away from this paper is that understanding Hyper-V and the underlying storage can greatly improve performance, manageability, and overall satisfaction with the virtualized environment.