Chapter 6
Virtualization and the Cloud
CERTIFICATION OBJECTIVES
6.01 Benefits of Virtualization in a Cloud Environment
6.02 Virtual Resource Migrations
Two-Minute DrillVirtualization is the key building block to cloud computing and it is used by cloud providers to offer services to cloud consumers. Virtualization is the component that makes it possible for cloud services to provide a scalable, elastic, and on-demand environment. For example, cloud services may have thousands of hypervisors. When a cloud consumer requests a new server, the cloud provider provisions a new virtual machine from a hypervisor. No new physical hardware needs to be put in place to service the request.
Virtualization allows an organization to easily scale its computing environment both up and down to meet its needs. When combined with cloud computing, virtualization takes advantage of the unlimited computing resources provided externally by a cloud provider to provide flexible and scalable virtualization solutions.
Virtualization will continue to play a big role in cloud computing, as it is the technology that allows a cloud provider to deliver low-cost hosting environments to organizations no matter the size of the enterprise.
CERTIFICATION OBJECTIVE 6.01
Benefits of Virtualization in a Cloud Environment
Cloud computing and virtualization go hand in hand. Virtualization makes cloud computing more efficient and easier to manage. Virtualization consolidates many physical servers into virtual machines running on fewer physical servers functioning as hosts. Through virtualization, a single host can run many guest operating systems and multiple applications instead of a single application on each server. Virtualization reduces the number of servers needed to host IT services, in turn lessening rack space, power consumption, and administration.
Virtualization transforms compute resources into a centralized, sharable pool of resources that an organization can allocate to its business units on demand while still maintaining control of resources and applications.
Shared Resources
Cloud computing can provide compute resources as a centralized resource through shared resources. Shared resources are distributed on an as-needed basis to the cloud consumer. Thus, sharing resources improves efficiency and reduces costs for an organization.
Virtualization helps to simplify the process of sharing compute resources. As we discussed in Chapter 5, virtualization also increases the efficiency of hardware utilization. The cloud, on the other hand, adds a layer of management that allows a virtual machine to be created quickly and scaled to meet the demands of the organization.
Figure 6-1 shows an example of how shared resources are configured.
FIGURE 6-1 An illustration of shared resources in a cloud environment
Elasticity
Elastic computing allows compute resources to vary dynamically to meet a variable workload. A primary reason organizations implement a cloud computing model is the ability to dynamically increase or decrease the compute resources of their virtual environment.
A cloud provider can support elasticity by using resource pooling. Resource pooling allows compute resources to be pooled to serve multiple consumers by using a multitenant model. Resource pooling can provide a unique set of resources to cloud consumers so that physical and virtual resources can be dynamically assigned and reassigned based on cloud consumer demands.
With cloud computing and elasticity, the time to add or remove cloud resources and the time it takes to implement an application can both be drastically reduced. When an organization implements cloud computing and virtualization, it can quickly provision a new server to host an application and then provision that application, which in turn reduces the time it takes to implement new applications and services.
Elasticity allows an organization to scale resources up and down as an application or service requires. In this scenario the organization becomes a cloud consumer and the resources in the cloud appear to the consumer to be infinite, allowing the organization to consume as much or as few resources as it requires. With this new scalable and elastic computing model, an organization can respond to compute resource demands in a quick and efficient manner, saving it time and money. Not only can a cloud consumer dynamically scale the resources it needs, but it can also migrate its applications and data between cloud providers, making the applications portable. With the cloud, an organization can deploy applications to any cloud provider, making its applications portable and scalable.
While virtualization alone could provide many of these same benefits of elasticity and scalability, it would rely on compute resources being purchased and owned by the organization rather than leased from a seemingly infinite resource like a cloud provider.
Elasticity allows an organization to quickly and easily scale the virtual environment both up and down, as needed.
Another benefit of combining cloud computing and virtualization is the ability to self-provision virtual systems. An IT department in a cloud computing model can grant permissions that give users in other departments the ability to self-provision virtual machines. The IT department still controls how the virtual machine is created and what resources are provided to that virtual machine without actually having to create it. The IT department even can charge or keep track of the users who are creating the virtual machine, making the users accountable for whether they actually need the machine and the resources it requires.
Network and Application Isolation
As discussed previously, cloud computing and virtualization can enhance network security, increase application agility, and improve scalability and availability of the environment. Cloud computing can also help to create network and application isolation.
Without network isolation, it might be possible for a cloud consumer to intentionally or unintentionally consume a significant share of the network fabric or see another tenant’s data in a multitenant environment. Proper configuration of the network to include resource control and security using network isolation helps to ensure these issues are mitigated.
There are also circumstances where certain network traffic needs to be isolated to its own network to provide an initial layer of security, to afford higher bandwidth for specific applications, to enforce chargeback policies, or for use in tiered networks.
Virtualization and cloud computing now provide a means to isolate an application without having to deploy a single application to a single physical server. By combining virtualization and network isolation, it is possible to isolate an application just by correctly configuring a virtual network. Multiple applications can be installed on one physical server and then a given application can be isolated so that it can communicate only with network devices on the same isolated segment.
For example, you can install an application on a virtual machine that is the same version or a newer version of an existing application yet have that install be completely isolated to its own network for testing. The ability for an organization to isolate an application without having to purchase additional hardware is a key factor in the decision to move to virtualization and cloud computing.
Virtualization makes it possible for an application to be installed on a virtual machine and be isolated from other network devices. This feature is typically utilized in the entry-level stages of testing applications because the identical environment running in the IT department can be easily replicated.
Infrastructure Consolidation
Virtualization allows an organization to consolidate its servers and infrastructure by allowing multiple virtual machines to run on a single host computer and even providing a way to isolate a given application from other applications that are installed on other virtual machines on the same host computer. Cloud computing can take it a step further by allowing an organization not only to benefit from virtualization but also to purchase compute resources from a cloud provider. If an organization purchases its compute resources from a cloud provider, it requires fewer hardware resources internally.
Cost Considerations
Consolidating an organization’s infrastructure using virtualization and cloud compute resources results in lower costs to the organization since it no longer needs to provide the same power, cooling, administration, and hardware that would be required without virtualization and cloud computing. The organization can realize additional cost savings in reduced time spent on maintaining the network environment since consolidated infrastructure is often easier to manage and maintain.
Energy Savings
Consolidating an organization’s infrastructure using virtualization and cloud compute resources results in lower energy consumption to the organization since it no longer needs to provide the same power to equipment that was virtualized or replaced by cloud compute resources. Less hardware also results in reduced cooling needs and less square footage used in an office space.
Dedicated vs. Shared Compute Environment
A dedicated compute environment offers consistent performance because the organization does not need to contend with other tenants for compute resources. However, a dedicated compute environment is more expensive to lease than a shared compute environment because the cloud provider cannot distribute the costs for the compute resources over as many tenants.
Dedicated resources may be a requirement for some regulated industries or for companies with specific data handling or isolation contractual requirements.
Virtual Data Center Creation
Another option an organization has regarding infrastructure consolidation is a virtual data center. A virtual data center offers data center infrastructure as a service and is the same concept as a physical data center with the advantages of cloud computing mixed in.
A virtual data center offers compute resources, network infrastructure, external storage, backups, and security just like a physical data center. A virtual data center also offers virtualization, pay-as-you-grow billing, elasticity, and scalability. An administrator can control the virtual resources by using quotas and security profiles.
A cloud user of a virtual data center can create virtual servers and host applications on those virtual servers based on the security permissions assigned to their user account. It is also possible to create multiple virtual data centers based on either geographic or application isolation requirements.
CERTIFICATION OBJECTIVE 6.02
Virtual Resource Migrations
Now that you understand how cloud computing benefits from virtualization, you need to know how to migrate an organization’s current resources into either a virtual environment or a cloud environment.
Migrating servers to a virtual or cloud environment is one of the first steps in adopting a cloud computing model. Organizations do not want to start from scratch when building a virtual or cloud environment; they want the ability to migrate what is in their current data center to a cloud environment.
With the advancements in virtualization and consolidated infrastructures, organizations now see IT resources as a pool of resources that can be managed centrally, not as a single resource. IT administrators now can easily move resources across the network from server to server, from data center to data center, or into a private, public, or hybrid cloud, giving them the ability to balance resource and compute loads more efficiently across multiple, even global, environments.
This section explains the different options for migrating an organization’s current infrastructure to a virtual or cloud environment.
Virtual Machine Templates
When an organization is migrating its environment to the cloud, it needs to have a standardized installation policy or profile for its virtual servers. The virtual machines need to have a very similar base installation of the operating system so that all the machines have the same security patches, service packs, and base applications installed.
Virtual machine templates create a standardized set of virtual machine configuration settings that allow for quick deployment of one or multiple virtual machines.
Virtual machine templates provide a streamlined approach to deploying a fully configured base server image or even a fully configured application server. Virtual machine templates help decrease the installation and configuration costs when deploying virtual machines and lower ongoing maintenance costs, allowing for faster deploy times and lower operational costs.
A virtual machine template can be exported from one virtualization host, and then imported on another virtualization host and be used as a master virtual machine template for all virtualization hosts.
Virtual machine templates provide a standardized group of hardware and software settings that can repeatedly be reused to create new virtual machines that are configured with those specified settings. For example, a virtual machine template can be defined to create a virtual machine with 1024MB of memory, one vCPU, and three virtual hard disks. Alternatively, a virtual machine template can be set up based on an existing, fully configured virtual machine.
In essence, a virtual machine template acts as a master image that an organization can use to quickly and efficiently deploy similar virtual machine instances in its environment. The organization can then maintain the virtual machine templates by applying operating system updates and application patches so that any new virtual machine instances that are created with the template are up to date and ready to use instantly. Figure 6-2 displays a graphical representation of how virtual machine templates work.
FIGURE 6-2 Representation of a virtual machine template
Physical to Virtual (P2V)
Along with creating new virtual machines and provisioning those virtual machines quickly and efficiently using virtual machine templates, there will be occasions when an organization needs to convert a physical server to a virtual server. The process of creating a virtual machine from a physical server is called physical to virtual (P2V). Figure 6-3 illustrates how a P2V migration works.
FIGURE 6-3 A graphical representation of physical-to-virtual (P2V) migration
P2V enables the migration of a physical server’s operating system, applications, and data to a newly created guest virtual machine on a host computer. There are a three different ways to convert a physical server to a virtual server:
Manual You can manually create a new virtual machine on a host computer and copy all the files from the OS, applications, and data from the source physical server. The manual process is time-consuming and not very effective.
Semi-automated A semi-automated P2V approach uses a software tool to assist in the migration from a physical server to a virtual server. This simplifies the process and gives the administrator some guidance when migrating the physical server. There are also free software tools that help migrate a physical server from a virtual server.
Fully automated The fully automated version uses a software utility that can migrate a physical server over the network without any assistance from an administrator.
EXAM AT WORK
Migrating a Physical Environment to a Virtual Environment
A while back we were brought into an organization to explain the benefits of virtualization and the cloud and why this particular organization should look at virtualizing its data center. After many discussions and planning sessions, the organization decided that virtualization was the right step for it. We as the consultants were responsible for building and configuring the host computer along with the network and storage solution. After all of that was set up and configured, the next task was to migrate the organization’s systems from their current physical environment to a virtual environment. We presented the options of using a manual approach or automating the P2V conversion process. We ended up using a combination of manual and automated. Some physical servers were easier to migrate manually or were not supported for migration using the fully automated piece.
We helped the organization migrate its physical server to the virtual server using P2V on the noncritical servers first; then we worked toward the more critical application servers. The automated process is driven by a wizard and was run from the physical server. We loaded the P2V software on the physical server; stopped any services that might cause an issue during the migration; and answered the prompts of the wizard, telling it what host computer to migrate the server to, the name of the virtual machine, virtual hard disk, and so on. After successfully completing that process, the next step was to shut down the physical server and start the virtual server. Once the virtual server loaded, we had to install the guest tools and configure a few minor settings, with the final step to test the application that the server was running. After all the tests ran smoothly, our conversion of the physical server to a virtual server was complete.
Migrating a virtual machine from a physical server can be done either online or offline. With an online migration, the physical computer or source computer remains running and operational during the migration. One of the advantages of the online option is that the source computer is still available during the migration process. This may not be a big advantage, however, depending on the application that is running on the source computer.
When doing an offline P2V conversion, the source computer is taken offline during the migration process. An offline migration provides for a more reliable transition since the source computer is not being utilized. For example, if you are doing a migration of a database server or a domain controller, it would be better to do the migration offline since the system is constantly being utilized.
Before migrating a physical machine to a virtual machine, it is always advisable to check with the application vendor to make sure it supports the hardware and application in a virtual environment.
Virtual to Virtual (V2V)
Similar to P2V, virtual to virtual (V2V) is the process of migrating an operating system, applications, and data, but instead of migrating them from a physical server, they are migrated from a virtual server.
Just like for P2V, software tools are available to fully automate a V2V migration. V2V can be used to copy or restore files and programs from one virtual machine to another. It can also be used to convert a VMware virtual machine to a Hyper-V-supported virtual machine or vice versa.
If the conversion is from VMware to Hyper-V, the process creates a .vhdx file and copies the contents of the .vmdk file to the new .vhdx file so that the virtual machine can be supported in Hyper-V.
The Open Virtualization Format (OVF) is a platform-independent extensible open packaging and distribution format for virtual machines. OVF allows for efficient and flexible allocation of applications, making virtual machines mobile between vendors because the application is vendor and platform neutral. An OVF virtual machine can be deployed on any virtualization platform. Similarly, an Open Virtual Appliance (OVA) is an open standard for a virtual appliance that can be used in a variety of hypervisors from different vendors.
Virtual to Physical (V2P)
The virtual-to-physical (V2P) migration process is not as simple as a P2V. A variety of tools are needed to convert a virtual machine back to a physical machine. Here is a three-step process for doing a V2P conversion:
1. Generalize the virtual machine security identifiers. Install and run Microsoft Sysprep on the virtual machine to prepare the image for transfer and allow for hardware configuration changes.
2. Gather drivers. Prepare all the drivers for the target physical server before doing the migration.
3. Convert using a third-party tool. Use a software tool such as Symantec Ghost or Acronis Universal Restore to facilitate the virtual-to-physical conversion and load the necessary hardware drivers onto the physical machine.
While a V2P conversion is not something that is often done, sometimes it is required, for a couple of different reasons. One of the reasons is to test how the application performs on physical hardware. Some applications may perform better on physical hardware than on virtual hardware. This is not a common circumstance, however, and it is fairly easy to increase the compute resources for a virtual machine to improve the performance of an application that is hosted there.
The more common reason to perform a V2P is that some application vendors do not support their product running a virtual environment. Today almost all vendors do support their application in a virtual environment, but there are still a few who do not. This fact and the complexities of V2P over P2V make V2P a less common scenario. Unlike the P2V process, which requires only the software tool to do the migration, the V2P process involves more planning and utilities and is much more complex.
Virtual Machine Cloning
Whether an organization creates a virtual machine from scratch or uses one of the migration methods we just discussed, at some point it might want to make a copy of that virtual machine, called a clone.
Installing a guest operating system and all of the applications is a time-consuming process, so virtual machine cloning makes it possible to create one or multiple copies of a virtual machine or a virtual machine template. Clones can also be used to create virtual machine templates from existing machines.
When a company creates a virtual machine clone, it is creating an exact copy of an existing virtual machine. The existing virtual machine then becomes the parent virtual machine of the virtual machine clone. After the clone is created, it is a separate virtual machine that can share virtual disks with the parent virtual machine or create its own separate virtual disks.
Once the virtual machine clone is created, any changes made to the clone do not impact the parent virtual machine and vice versa. A virtual machine clone’s MAC address and universally unique identifier (UUID) are different from those of the parent virtual machine.
Virtual machine cloning allows for deploying multiple identical virtual machines to a group. This is useful in a variety of situations. For example, the IT department might create a clone of a virtual machine for each employee, and that clone would contain a group of preconfigured applications. Or the IT department might want to use virtual machine cloning to create a development environment. A virtual machine could be configured with a complete development environment and cloned multiple times to create a baseline configuration for testing new software and applications.
Virtual machine clones provide an efficient way to create a copy of a virtual machine to quickly deploy a development environment.
Virtual Machine Snapshots
A virtual machine snapshot captures the state of a virtual machine at the specific time that the snapshot is taken. A virtual machine snapshot can be used to preserve the state and data of a virtual machine at a specific point in time. Reverting to a snapshot is extremely quick compared to restoring from a backup.
It is common for snapshots to be taken before a major software installation or other maintenance. If the work fails or causes issues, the virtual machine can be restored to the state it was in when the snapshot was taken in a very short amount of time.
A snapshot includes the state the virtual machine is in when the snapshot is created. So if a virtual machine is powered off when the snapshot is created, the snapshot will be of a powered off machine. However, if the virtual machine is powered on, the snapshot will contain the RAM and current state so that restoring the snapshot will result in a running virtual machine at the point in time of the snapshot. The snapshot includes all the data and files that make up the virtual machine, including hard disks, memory, and virtual network interface cards.
Multiple snapshots can be taken of a virtual machine. A series of snapshots is organized into a snapshot chain. A snapshot keeps a delta file of all the changes after the snapshot was taken. The delta file records the differences between the current state of the virtual disk and the state the virtual machine was in when the snapshot was taken.
Clones vs. Snapshots
Clones and snapshots have distinct uses and it is important not to confuse their use cases. Virtual machine cloning is used when you want to make a separate copy of a virtual machine for either testing, separate use, or for archival purposes.
However, if you are looking to save the current state of a virtual machine so that you can revert to that state in case of a software installation failure or an administrative mistake, you should create a virtual machine snapshot, not a virtual machine clone.
Storage Migration
Storage migration is the process of transferring data between storage devices. Storage migration can be automated or done manually. Storage migration makes it possible to migrate a virtual machine’s storage or disks to a new location and across storage arrays while maintaining continuous availability and service to the virtual machine. It also allows for migrating a virtual machine to a different storage array without any downtime to the virtual machine. Figure 6-4 displays how storage is migrated between storage devices.
FIGURE 6-4 Using storage migration in a virtual environment
Storage migration eliminates service disruptions to a virtual machine and provides a live and automated way to migrate the virtual machine’s disk files from the existing storage location to a new storage destination. Migrating virtual machine storage to different classes of storage is a cost-effective way to manage virtual machine disks based on usage, priority, and need. It also provides a way to take advantage of tiered storage, which we discussed in Chapter 2.
Storage migration allows a virtual machine to be moved from SAN-based storage to NAS, DAS, or cloud-based storage according to the current needs of the virtual machine. Storage migration helps an organization prioritize its storage and the virtual machines that access and utilize that storage.
Host Clustering and HA/DR
High availability (HA) and disaster recovery (DR) functions of a hypervisor enable automatic failover with load balancing. In order to use HA, a cluster consisting of multiple hypervisors, typically utilizing shared storage, must be configured. Some systems require management tools such as VMware’s vSphere or Microsoft System Center Virtual Machine Manager to take advantage of some of the more advanced HA capabilities, profiles, and customization.
A high availability cluster auto-balances virtual machines across the available hypervisors. It can also fail a virtual machine over to another host if the host experiences issues or suffers from resource constraints. Each host in the cluster must maintain a reserve of resources so that it can support additional virtual machine migrations in the case of a host failure. HA clusters also periodically rebalance virtual machines across the cluster hosts to ensure that a comfortable resource ceiling is maintained.
Depending on the cluster size, some or all hosts in the cluster will be configured to monitor the status of other hosts and virtual machines. This is accomplished through heartbeat connections that essentially tell other nodes that the hypervisor or virtual machine is still active and functioning. If a heartbeat is not received from a host for a predetermined amount of time (15 seconds for VMware), the virtual machines on that host will be failed over to other hosts in the cluster and the host will be marked as inactive until a heartbeat signal is received again from the host.
Administrators should configure a dedicated network segment or VLAN for heartbeat traffic. Heartbeat traffic does not need to be routed if all hosts are in the same LAN. However, if hosts are spread across sites such as in multisite failover scenarios, the heartbeat network will need to be routed to the other site as well. In cloud environments, a VXLAN is a perfect solution for the heartbeat connection. VXLANs were covered in Chapter 4.
A dedicated virtual NIC does not need to be assigned to virtual machines on a cluster. The hypervisor client tools will send the heartbeat information to the hypervisor. Hypervisors can be configured to take specific actions if a heartbeat signal is not received from a virtual machine, such as restarting the virtual machine, notifying an administrator, reverting to a saved state, or failing the virtual machine over to another host.
CPU Effect on HA/DR
The hypervisor only has so much information when it chooses the placement of a virtual machine. Some virtual machines might not have many processors configured, but they are still processor intensive. If you find that your HA cluster frequently rebalances the machines in a suboptimal way, there are some actions you can take to remedy the situation.
HA resource determinations are based on a number of factors, including the following:
Defined quotas and limits
Which resource is requested by which virtual machine
The business logic that may be applied by a management system for either a virtual machine or a pool of virtual machines
The resources that are available at the time of the request
It is possible for the processing power required to make these decisions to outweigh the benefit of the resource allocations, and in those situations administrators can configure their systems to allocate specific resources or blocks of resources to specific hosts to shortcut that logic and designate which resources to use for a specific virtual machine or pool on all requests.
CPU affinity is one such application, in which processes or threads from a specific virtual machine are tied to a specific processor or core, and all subsequent requests from those processes or threads are executed by that same processor or core. Organizations can utilize reservations for virtual machines to guarantee an amount of compute resources for that virtual machine.
Cloud Provider Migrations
It may become necessary to migrate virtual machines or entire services from one cloud provider to another. There is a high level of standardization with cloud platforms, but the migration process still requires a high level of integration between cloud providers for seamless migration.
It is important, when evaluating cloud providers, to ensure that they offer integration and migration options. One cloud provider may not meet your scalability or security requirements, necessitating a move to another cloud provider. Additionally, you may wish to diversify cloud resources across several providers to protect against data loss or service downtime from a single provider’s downtime.
In worst-case scenarios, you may need to export the virtual machines into a compatible format and then manually import them or import them with a script into the new cloud provider’s environment.
Extending Cloud Scope
A major advantage of cloud systems is that cloud consumers can extend existing workloads into the cloud or extend existing cloud systems, making the cloud a powerful and flexible system for companies to rely upon for changing business needs.
CERTIFICATION OBJECTIVE 6.03
Migration Considerations
Before an organization can migrate a virtual machine using one of the migration methods discussed in the previous section, it needs to consider a few things. Among the most important of those considerations are the compute resources: the CPU, memory, disk I/O, and storage requirements. Migrating a physical server to a virtual machine takes careful planning for it to be successful. Planning the migration of physical servers to the virtual environment is the job of IT administrators, and it is critical that they perform their due diligence and discover all the necessary information about both the server and the application that the server is hosting.
Requirements Gathering
It is important to gather as much information as possible when preparing to migrate physical servers to a virtual environment. This information will help in determining which servers are good candidates for migration and which of those servers to migrate first.
When evaluating a physical server to determine if it is a good candidate for a virtual server, it is important to monitor that server over a period of time. The monitoring period helps to produce an accurate profile of the physical server and its workload.
A monitoring tool such as Windows Performance Monitor or a comparable tool in the Linux environment can be used to get an accurate assessment of the resource usage for that particular server. The longer the trends of the physical server are monitored, the more accurate the evaluation of resource usage will be.
The time spent monitoring the system also varies depending on the applications the physical server is hosting. For example, it would make sense to monitor a database server for a longer period than a print server. In the end, the organization needs to have an accurate picture of memory and CPU usage under various conditions so that it can use that information to plan the resources the physical server might need after it is converted to a virtual machine.
Another consideration to make when determining if a physical server is a good candidate for virtualization is the status of the file system. When converting a physical server to a virtual server, all the data from the physical server is copied to the virtual server as part of the P2V process. Files and data that are not required are sometimes kept on a server, and those files do not need to be migrated as part of the P2V process, nor should they be. It is important, then, to examine the hard drive of the physical server before performing a migration and to remove all files and data that are not required for the server to function and provide the application it is hosting. Examples of these files might be drivers or hardware application such as Wi-Fi tools, firmware update utilities, or other files meant to be used only by a physical machine.
During a P2V migration, the host computer must support the source computer’s memory.
Migration Scheduling
After gathering the proper information to perform a successful physical-to-virtual migration, you need to plan when the project should be completed. Migrations will not result in downtime for systems that meet online migration requirements of your specific P2V migration tool such as the VMware vCenter converter or the Microsoft virtual machine converter. However, systems under migration will likely experience slower performance while the migration is underway. It may be advisable to schedule migrations during a downtime or a period where activity is typically at its lowest, such as in the late evening or overnight.
Expect some downtime as part of the migration of a physical server to a virtual server if it does not meet the requirements of your P2V conversion tool. At a minimum, the downtime will consist of the time to start the new virtual machine and shut down the old physical server. DNS changes may also need to be made and replicated to support the new virtual instance of the physical server.
Maintenance schedules should also be implemented or taken into consideration when planning the migration of a physical server to a virtual server. Most organizations have some maintenance schedule set up for routine maintenance on their server infrastructure, and these existing scheduled blocks of time might be suitable for P2V conversions.
Provide the business case for some downtime of the systems to the change management team before embarking on the P2V migration process. Part of that downtime goes back to the resource provisioning discussion earlier in this chapter. It is a balance between under-provisioning the new virtual servers from the beginning or over-provisioning resources. Under-provisioning causes additional and unnecessary downtime of the virtual server and the application the virtual server is hosting. On the other hand, over-provisioning reserves too many resources to the virtual machine and consumes precious host resources where they are not required. This can sometimes even have a detrimental effect on performance.
Upgrading
In addition to P2V, V2P, and V2V, an organization also may upgrade an existing virtual machine to the latest virtual hardware or latest host operating system. Virtual machine hardware corresponds to the physical hardware available on the host computer where the virtual machine is created.
It may be necessary to upgrade the virtual machine hardware or guest tools on a virtual machine to take advantage of some of the features that the host provides. The host file system or hypervisor may also need to be updated to support these improvements. Virtual machine hardware features might include BIOS enhancements, virtual PCI slots, and dynamically configuring the number of vCPUs or memory allocation.
Another scenario that might require upgrading a virtual machine is when a new version of the host operating system is released (e.g., when Microsoft releases a new version of Hyper-V or VMware releases a new version of ESXi). In this instance, an organization would need to upgrade or migrate its virtual machines to the new host server.
Upgrading to a new host operating system and migrating the virtual machines to that new host requires the same planning that would be needed to perform a P2V migration. Make sure you understand the benefits of the new host operating system and how those benefits will impact the virtual machines and, specifically, their compute resources. Once again, careful planning is key before the upgrading process starts.
Workload Source and Destination Formats
The simplest migrations are performed when source and destination formats are the same, but life is not always simple and there will be times when an upgrade includes transitioning from one format to another.
Migrations or upgrades may include transitioning P2V, V2P, or V2V and from one platform such as Microsoft Hyper-V to VMware or Citrix XenServer. Migrations may also involve more advanced features such as virtual disk encryption or multifactor authentication that must be supported and configured on the destination server.
Virtualization Format P2V migrations can be performed manually by setting up a new operating system and then installing applications, migrating settings, and copying data. However, this is time-consuming and often error-prone. It is more efficient to use software tools to fully or partially automate the P2V conversion process. Tools are specific to the destination virtualization platform and such tools gather the required information from the physical machine and then create a virtual machine on the destination virtualization platform such as Hyper-V or VMware.
V2P migrations can be performed by running Microsoft Sysprep on the virtual machine to prepare the image for transfer and allow for hardware configuration changes. Next, all the drivers for the target physical server would need to be prepared before doing the migration, and then a software tool would be used to facilitate the virtual-to-physical migration and load the necessary hardware drivers onto the physical machine. Alternatively, V2P migrations can be performed manually by setting up a new operating system and then installing applications, migrating settings, and copying data.
V2V migration can be performed by exporting the virtual machines from the previous version and importing them into the new version of the host operating system software. Additionally, some software such as VMware VMotion or Microsoft SCVMM can perform migrations from one hypervisor version to another. However, this is often a one-way move because moving from a newer version to an older version is not usually supported.
Application and Data Portability Migrations also may move from an encrypted format to a nonencrypted format or vice versa. Migrating encrypted virtual machines does require the encryption keys, so you must ensure that these are available prior to migration and ensure that the destination system supports the same encryption standards. Certificates or other prerequisites may need to be in place first to support this or other features of the virtual machine.
Standard Operating Procedures for Workload Migrations
It is likely that you will perform migrations many times. The first time you perform a migration, create a standard process for future migrations. You may find along the way that you can improve the process here or there. Feel free to add more details to the standard process as you discover enhancements.
A standard process ensures that others who perform the same task will do so with the same level of professionalism that you do. Standard operating procedures also ensure consistent implementation, including the amount of time it takes to perform the task and the resources required.
Standard operating procedures can also be used to automate processes. Once a process has been performed several times and is sufficiently well documented, there may be methods of automating the process so that it is even more streamlined. The documentation will ensure that you do not miss a critical step in the automation and it can help in troubleshooting automation later on.
Environmental Constraints
Upgrades are also dependent upon various environmental constraints such as bandwidth, working hour restrictions, downtime impact, peak timeframes, and legal restrictions. We also operate in a global economy, so it is important to understand where all users are operating and the time zone restrictions for performing upgrades.
Bandwidth Migrations can take a lot of bandwidth depending on the size of the virtual machine hard drives. When migrating over a 1 Gbps or 10 Gbps Ethernet network, this is not as much of a concern, but bandwidth can be a huge constraint when transferring machines over a low-speed WAN link such as a 5 Mbps MPLS connection.
Evaluate machines that are to be migrated and their data sizes and then estimate how much time it will take to migrate the machines over the bandwidth available. Be sure to factor in other traffic as well. You do not want the migration to impact normal business operations in the process. Also, be sure that others are not migrating machines at the same time.
Working Hour Restrictions Working hours can be a restriction on when upgrades or migrations are performed. Working hour restrictions may require that some work be performed outside of normal business hours, such as before 9:00 a.m. or after 5:00 p.m. Working hours may differ in your company. For example, they may be 7:00 a.m. till 7:00 p.m. in places where 12-hour shifts are common.
Working hour restrictions also impact how work is assigned to people who work in shifts. For example, if an upgrade is to take three hours by one person, then it must be scheduled at least three hours prior to the end of that person’s shift or the task will need to be transitioned to another team member while still incomplete. It generally takes more time to transition a task from one team member to another, so it is best to try to keep this to a minimum. Sometimes more than one person works on a task, but those people leave and a new group takes over at some point so that a single person or group does not get burned out trying to complete a major task.
It is also important to factor in some buffer time for issues that could crop up. In the example, if the task is expected to take three hours and you schedule it exactly three hours before the employee’s shift ends, that provides no time for troubleshooting or error. If problems do arise, the task would be transitioned to another team member who would need to do troubleshooting that might require input from the first team member in order to avoid rework since the second employee may not know everything that was done in the first place. For this reason, it is important to keep a detailed log of what changes were made and which troubleshooting steps were performed, even if you do not anticipate transitioning the task to another person. This can also be helpful when working with technical support.
Downtime Impact Not all migrations and upgrades require downtime, but it is very important to understand which ones do. Upgrades or migrations that require the system to be unavailable must be performed during a downtime. Stakeholders, including end users, application owners, and other administrative teams, need to be consulted prior to scheduling a downtime so that business operations are not impacted. The stakeholders need to be informed how long the downtime is anticipated to take, what value the change brings to them, and the precautions that the IT team is taking to protect against risks.
For systems that are cloud-consumer facing, if the cloud provider can’t avoid downtime to conduct a migration or upgrade, it needs to schedule the downtime well in advance and give cloud consumers plenty of notice so that the company does not lose cloud-consumer confidence by taking a site, application, or service down unexpectedly.
Peak Timeframes Upgrades that do not require downtime could still impact the performance of the virtual machine and the applications that run on top of it. For this reason, it is best to plan upgrades or migrations for times when the load on the system is minimal.
For example, it would be a bad idea to perform a migration on a DHCP server at the beginning of the day when users are logging into systems, because that is when the DHCP server has the greatest load. Users would likely see service interruptions if a migration or an upgrade were to take place during such a peak time.
Legal Restrictions Migrating a virtual machine from one location to another can present data sovereignty issues. Different countries have different laws, especially when it comes to privacy, and you will need to understand the type of data that resides on virtual machines and any limitations to where those virtual machines can reside.
Upgrades can also run into legal constraints when new features violate laws in the host country. For example, an upgrade may increase the encryption capabilities of software to a degree that it violates local laws requiring no more than a specific encryption bit length or set of algorithms.
Legal constraints can come up when upgrades violate laws for users of the system even if the application resides in a different country from the users. For example, the European Union’s General Data Protection Regulation (GDPR) affects companies that do business with Europeans even if those businesses are not located in Europe. Consult with legal and compliance teams to ensure that you adhere with local laws and regulations.
Time Zone Constraints Virtualized and cloud systems may have users spread across the globe. Additionally, it may be necessary to coordinate resources with cloud vendors or with support personnel in different global regions. In such cases, time zones can be a large constraint for performing upgrades. It can be difficult to coordinate a time that works for distributed user bases and maintenance teams.
For this reason, consider specifying in vendor contracts and SLAs an upgrade schedule so that you do not get gridlocked by too many time zone constraints and are unable to perform an upgrade.
Follow the Sun (FTS) Follow the sun (FTS) is a method where multiple shifts work on a system according to their time zone to provide 24/7 service. FTS is commonly used in software development and customer support. For example, customer support calls might be answered in India during India’s normal working hours, after which calls are transitioned to the Philippines, and so on, so that each group works its normal business hours. Similarly, a cloud upgrade could be staged so that teams in the United States perform a portion of the upgrade and then as soon as they finish, a team in the UK starts on the next batch. When the UK team completes their work, a team in China begins, and then back to the United States the following morning.
Testing
The process of P2V, or V2V for that matter, generally leaves the system in complete working and functional order and the entire system is migrated and left intact. With that said, any system that is being migrated should be tested both before and after the migration process. The IT administrator needs to define a series of checks that should be performed after the migration and before the virtual server takes over for the physical server. Some of the tests that should be completed on the virtual server after migration are as follows:
Remove all unnecessary hardware from the virtual machine. (If you are migrating from a physical server to a virtual server, you might have some hardware devices that were migrated as part of the P2V process.)
When first booting the virtual machine, disconnect it from the network. This allows the boot to occur without having to worry about duplicate IP addresses or DNS names on the network.
Reboot the virtual machine several times to clear the logs and verify that it is functioning as expected during the startup phase.
Verify network configurations on the virtual server while it is disconnected from the network. Make sure the IP address configuration is correct so that the virtual machine does not have any issues connecting to the network once network connectivity is restored.
Performing these post-migration tests will help to ensure a successful migration process and to minimize any errors that might arise after the migration is complete. As with anything, there could still be issues once the virtual machine is booted on the network, but performing these post-conversion tests will lessen the likelihood of problems.
CERTIFICATION SUMMARY
There are many benefits to adopting a virtualized environment, including shared resources, elasticity, and network isolation for testing applications. Migrating to a virtual environment takes careful planning and consideration to define proper compute resources for the newly created virtual machine. Understanding how to correctly perform a physical-to-virtual (P2V) migration is a key concept for the test and the real world, as you will be required to migrate physical servers to a virtual environment if you are working with virtualization or the cloud.
KEY TERMS
Use the following list to review the key terms discussed in this chapter. The definitions also can be found in the glossary.
dedicated compute environment Environment where a single tenant owns or leases equipment.
downtime Any time when the system is unavailable. Downtime can be reduced through various levels of redundancy.
elasticity Allows an organization to dynamically provision and deprovision processing, memory, and storage resources to meet the demands of the network.
follow the sun (FTS) A method where multiple shifts work on a system according to their time zone to provide 24/7 service.
network isolation Allows for a section of the network to be isolated from another section so that multiple identical copies of the environment are executed at the same time.
offline migration Migrates a physical server to a virtual machine by taking the source computer offline so that it is not available during the migration process.
online migration Migrates a physical server to a virtual machine while the source computer remains available during the migration process.
Open Virtual Appliance (OVA) An open standard for a virtual appliance that can be used in a variety of hypervisors from different vendors.
Open Virtualization Format (OVF) An open standard for a virtual hard disk that can be used in a variety of hypervisors from different vendors.
physical to physical (P2P) A transfer of the data and applications from one physical server to another physical server.
physical to virtual (P2V) Process of migrating a physical server’s operating system, applications, and data from the physical server to a newly created guest virtual machine on a virtualization host.
resource pooling Allows compute resources to be pooled to serve multiple consumers by using a multitenant model.
shared compute environment Environment where multiple tenants share resources from a cloud vendor or hosting provider.
shared resources Allows a cloud provider to provide compute resources as a centralized resource and distribute those resources on an as-needed basis to the cloud consumer.
storage migration Process of transferring data between storage devices, allowing data from a virtual machine to be migrated to a new location and across storage arrays while maintaining continuous availability and service to the virtual machine.
virtual data center Provides compute resources, network infrastructure, external storage, backups, and security similar to a physical data center.
virtual machine cloning Allows a virtual machine to be copied either once or multiple times for testing.
virtual machine snapshotting A method of capturing the state of a virtual machine at a specific point in time.
virtual machine template Provides a standardized group of hardware and software settings that can be reused multiple times to create a new virtual machine that is configured with those specified settings.
virtual to physical (V2P) Migrates a virtual machine to a physical computer.
virtual to virtual (V2V) Migrates an operating system, applications, and data from one virtual machine to another virtual machine.
TWO-MINUTE DRILL
Benefits of Virtualization in a Cloud Environment
Virtualization consolidates many physical servers into virtual machines running on fewer physical servers functioning as hosts. Through virtualization, a single host can run many guest operating systems and multiple applications instead of a single application on each server.
Cloud computing can provide compute resources as a centralized resource through shared resources. Shared resources are distributed on an as-needed basis to the cloud consumer. Shared resources, thus, improve efficiency and reduce costs for an organization. Elastic computing allows compute resources to vary dynamically to meet a variable workload and to scale up and down as an application requires.
Virtualization allows for segmenting an application’s network access and isolating that virtual machine to a specific network segment.
Virtualization allows an organization to consolidate its servers and infrastructure by having multiple virtual machines run on a single host computer.
Virtual data centers offer data center infrastructure as a service; they have the same capabilities as a physical data center but with the advantages of cloud computing.
Virtual Resource Migrations
A virtual machine template provides a standardized group of hardware and software settings that can be deployed quickly and efficiently to multiple virtual machines.
The process of migrating a physical server to a virtual server is called physical to virtual (P2V).
P2V allows you to convert a physical server’s operating system, applications, and data to a virtual server.
Virtual-to-virtual (V2V) migrations allow you to migrate a virtual machine to another virtual machine by copying the files, operating system, and applications from one virtual machine to another.
An online migration of a physical server to a virtual server leaves the physical server running and operational during the migration process.
If an application does not support installation on a virtual server, virtual-to-physical (V2P) migration can be used to copy the virtual machine to a physical server.
Virtual machine cloning creates an exact copy of a virtual machine for use in a development or test environment.
Virtual machine snapshots capture the state of a virtual machine at a specific point in time. Snapshots can return the machine to that state easily and efficiently if so desired.
A virtual machine’s virtual hard disk can be migrated from one storage device to another using storage migration. This allows you to take advantage of tiered storage.
High availability (HA) and disaster recovery (DR) functions of a hypervisor enable automatic failover with load balancing.
It may become necessary to migrate virtual machines or entire services from one cloud provider to another. A high level of integration is needed between cloud providers for a seamless migration.
Migration Considerations
Migrating a physical server to a virtual server takes careful planning to be successful.
It is very important for an organization to gather all the hardware and application requirements of a physical server before migrating it to a virtual server.
It is advisable to migrate a physical server to a virtual server during scheduled and planned maintenance hours.
Proper testing of a virtual machine after the P2V migration process is required to verify that the virtual server is operating at peak performance.
SELF TEST
The following questions will help you measure your understanding of the material presented in this chapter. As indicated, some questions may have more than one correct answer, so be sure to read all the answer choices carefully.
Benefits of Virtualization in a Cloud Environment
1. Which of the following allows you to scale resources up and down dynamically as required for a given application?
A. Subnetting
B. Resource pooling
C. Elasticity
D. VLAN
2. Which of the following data centers offers the same concepts as a physical data center with the benefits of cloud computing?
A. Private data center
B. Public data center
C. Hybrid data center
D. Virtual data center
3. How does virtualization help to consolidate an organization’s infrastructure?
A. It allows a single application to be run on a single computer.
B. It allows multiple applications to run on a single computer.
C. It requires more operating system licenses.
D. It does not allow for infrastructure consolidation and actually requires more compute resources.
4. Which of the following gives a cloud provider the ability to distribute resources on an as-needed basis to the cloud consumer and in turn helps to improve efficiency and reduce costs?
A. Elasticity
B. Shared resources
C. Infrastructure consolidation
D. Network isolation
Virtual Resource Migrations
5. Your organization is planning on migrating its data center, and you as the administrator have been tasked with reducing the footprint of the new data center by virtualizing as many servers as possible. A physical server running a legacy application has been identified as a candidate for virtualization. Which of the following methods would you use to migrate the server to the new data center?
A. V2V
B. V2P
C. P2P
D. P2V
6. You have been tasked with migrating a virtual machine to a new host computer. Which migration process would be required?
A. V2V
B. V2P
C. P2P
D. P2V
7. An application was installed on a virtual machine and is now having issues. The application provider has asked you to install the application on a physical server. Which migration process would you use to test the application on a physical server?
A. V2V
B. V2P
C. P2P
D. P2V
8. You have been tasked with deploying a group of virtual machines quickly and efficiently with the same standard configurations. What process would you use?
A. V2P
B. P2V
C. Virtual machine templates
D. Virtual machine cloning
9. Which of the following allows you to migrate a virtual machine’s storage to a different storage device while the virtual machine remains operational?
A. Network isolation
B. P2V
C. V2V
D. Storage migration
10. You need to create an exact copy of a virtual machine to deploy in a development environment. Which of the following processes is the best option?
A. Storage migration
B. Virtual machine templates
C. Virtual machine cloning
D. P2V
11. You are migrating a physical server to a virtual server. The server needs to remain available during the migration process. What type of migration would you use?
A. Offline
B. Online
C. Hybrid
D. V2P
Migration Considerations
12. You notice that one of your virtual machines will not successfully complete an online migration to a hypervisor host. Which of the following is most likely preventing the migration process from completing?
A. The virtual machine needs more memory than the host has available.
B. The virtual machine has exceeded the allowed CPU count.
C. The virtual machine does not have the proper network configuration.
D. The virtual machine license has expired.
13. After a successful P2V migration, which of the following tests, if any, should be completed on the new virtual machine?
A. Testing is not required.
B. Remove all unnecessary software.
C. Verify the IP address, DNS, and other network configurations.
D. Run a monitoring program to verify compute resources.
14. You are planning your migration to a virtual environment. Which of the following physical servers should be migrated first? (Choose two.)
A. A development server
B. A server that is running a non-mission-critical application and is not heavily utilized day to day
C. A highly utilized database server
D. A server running a mission-critical application
SELF TEST ANSWERS
Benefits of Virtualization in a Cloud Environment
1. 
C. Elasticity allows an organization to scale resources up and down as an application or service requires.
A, B, and D are incorrect. Subnetting is the practice of creating subnetworks, or subnets, which are logical subdivisions of an IP network. Resource pooling allows compute resources to be pooled to serve multiple consumers by using a multitenant model. A virtual local area network (VLAN) is the concept of partitioning a physical network to create separate independent broadcast domains that are part of the same physical network.
2. D. A virtual data center offers compute resources, network infrastructure, external storage, backups, and security, just like a physical data center. A virtual data center also offers virtualization, pay-as-you-grow billing, elasticity, and scalability.
A, B, and C are incorrect. The other options are definitions of cloud deployment and service models.
3. B. Virtualization allows an organization to consolidate its servers and infrastructure by allowing multiple virtual machines to run on a single host computer.
A, C, and D are incorrect. These options would not help to consolidate an organization’s infrastructure.
4. B. Shared resources give a cloud provider the ability to distribute resources on an as-needed basis to the cloud consumer, which helps to improve efficiency and reduce costs for an organization. Virtualization helps to simplify the process of sharing compute resources.
A, C, and D are incorrect. Elasticity allows an organization to scale resources up and down as an application or service requires but does not give the cloud provider the ability to distribute resources as needed. Infrastructure consolidation allows an organization to consolidate its physical servers into a smaller virtualized data center but is not used to distribute resources automatically. Network isolation allows you to isolate the network the virtual machine is connected to but has nothing to do with distributing resources.
Virtual Resource Migrations
5. D. P2V would allow you to migrate the physical server running the legacy application to a new virtual machine in the new virtualized data center.
A, B, and C are incorrect. These options do not allow you to migrate the physical server running the legacy application to a new virtual server.
6. A. V2V would allow you to migrate the virtual machine to a new virtual machine on the new host computer.
B, C, and D are incorrect. These options would not be the most efficient way to migrate a virtual machine to a new host computer.
7. B. One of the primary reasons for using the V2P process is to migrate a virtual machine to a physical machine to test an application on a physical server if requested by the application manufacturer.
A, C, and D are incorrect. These options do not allow you to migrate a virtual machine to a physical server.
8. C. Virtual machine templates would allow you to deploy multiple virtual machines and those virtual machines would have identical configurations, which streamlines the process.
A, B, and D are incorrect. When you create a virtual machine clone, you are creating an exact copy of an existing virtual machine. P2V and V2P do not allow you to deploy multiple standardized virtual machines.
9. D. Storage migration is the process of transferring data between storage devices and can be automated or done manually and allows the storage to be migrated while the virtual machine continues to be accessible.
A, B, and C are incorrect. Network isolation allows you to isolate the network the virtual machine is connected to. P2V and V2V migrate the entire virtual machine or physical server, not just the virtual machine’s storage.
10. C. When you create a virtual machine clone, you are creating an exact copy of an existing virtual machine.
A, B, and D are incorrect. Virtual machine templates provide a streamlined approach to deploying a fully configured base server image or even a fully configured application server but do not create an exact copy of a virtual machine. Storage migration migrates the virtual machine’s storage to another storage device; it does not create an exact copy of the virtual machine. P2V would allow you to create a copy of a physical machine as a virtual machine, not an exact copy of a virtual machine.
11. B. With an online migration the physical computer or source computer remains running and operational during the migration.
A, C, and D are incorrect. An offline migration requires the server to be shut down before the migration process can take place.
Migration Considerations
12. A. During a P2V migration the host computer must support the source computer’s memory. More than likely the host does not have enough available memory to support the import of the virtual machine in a migration scenario.
B, C, and D are incorrect. These settings would need to be planned and thought out, but they would not prevent a virtual machine from being migrated to a host computer.
13. C. After a successful migration, the network settings should be checked and verified before bringing the virtual machine online.
A, B, and D are incorrect. Testing the virtual machine after a successful migration is something that should always be done. Testing the performance of the virtual machine should be done after the network settings have been configured and verified.
14. A and B. When planning a migration from a physical data center to a virtual data center, the first servers that should be migrated are noncritical servers that are not heavily utilized. A development server would be a good candidate since it is most likely not a mission-critical server.
C and D are incorrect. You would not want to migrate mission-critical or highly utilized servers before migrating noncritical servers. This helps to prevent downtime of critical applications and provides a means of testing the migration process and the virtual environment before migrating critical servers to the virtual environment.