Lately, there has been in increase in IT organizations migrating their traditional virtualization workloads to open-source platforms such as Red Hat Enterprise Virtualization (RHEV) . Although there are many reasons for migrating (e.g. cost, features), one key advantage stands out for the open source alternatives. Organizations are now seeing the viability of building on the same platform to integrate open source cloud solutions with traditional applications. No single platform is optimized for each workload type or tier. Not only do organizations get to take advantage of the fast innovation of open source, but they also realize significant cost savings.

The first question to ask when migrating traditional applications is “where to start?” My advice is to not rush into evaluating v2v tools to automate migration of virtual machines. A v2v tool is a critical part of the process, but technology without some thoughtful analysis will lead to project failure. It pays greater dividends to spend a little time analyzing the environment before we start migrating.

In order or priority, here are five key areas to focus your efforts on before migrating applications from one platform to another.

1. Workload Profiling

Your existing virtual machines have probably been around for a long time and may have even been created using a P2V process. Over the years, resources have been added and the configuration is not consistent. Perhaps you even oversized the VMs due to virtualization performance concerns. It could also be that the VMs are overutilized, so actual workload requirements are difficult to understand. Because of oversubscription and resource management at the hypervisor level, you need to consider workload profiles for the guest and the hypervisor. Now is the time to consider optimizing the environment as part of the migration. To analyze performance and capacity sizing for operating systems, ensure that you have a full understanding of:

  • CPU utilization & process execution latency
  • Memory utilization and access latency
  • Disk utilization and read/write wait times
  • Network utilization, errors and latency

2. Architecture Analysis

Virtualization is virtualization right? I should be able to move my VM from one place to another without any re-architecting. Yes and no. Each virtualization platform has specific characteristics and configurables. Your virtual machines have been architected to live in a specific environment. You need to understand those dependencies and either emulate them in the new environment or re-architect the virtual machine during the migration process. Below are some dependencies to pay special attention to:

  • Storage architecture - Filesystem locations, multipath, snapshotting
  • Network dependencies - Interface names, addresses, routing.
  • Application dependencies - Is there any component of the application that relies on specific characteristics at the infrastructure layer (e.g. network,cpu, storage)?
  • HW passthrough requirements - common in VDI environments for graphics processing or with specific interface cards for specialist industry use cases.
  • Guest Support - Each provider supports a certain range of guests and particularly versions. There is also variability in support of paravirtualized drivers.

3. Operations

This could be rightfully included in the architecture analysis, but I prefer to give it special attention. Where the Architecture Analysis looks from inside the VM and identifies its dependencies on the virtual infrastructure, an operational analysis looks from the perspective of an operations teams looking at the virtualized infrastructure. The simple aspects are:

  • High availability - Design it to keep it running. Performing a Single Point of Failure analysis (SPOF) is a valuable process.
  • Backup - Ensure that your infrastructure can recover from a disaster. Do your current tools work with the new infrastructure ? Are there better tools? Are recovery times impacted?
  • Monitoring - Infrastructure management requires that you have tools to keep it healthy. What is available from the VM infrastructure? Can it be integrated with your enterprise toolsets?

4. Lifecycle Management

A virtualize infrastructure is a production software environment. Like all applications it ages, has bugs and from time to time, completely fails. You must have all the processes and tools in place to manage this lifecycle. Hopefully you have this automated or at least semi-automated. Things to pay attention to include:

  • Patching and Updating - Are you relying on built in tools from the VM infrastructure solution or do you use external orchestration? Does that orchestration support the new VM infrastructure?
  • Deployment - Same as patching and updating.
  • Development Environments - What environments do you have for your developers?
  • Testing - Ensure that you have functional testing capabilities for the VM infrastructure itself.

5. V2V Implementation

Finally you should now have some confidence to be ready to migrate the VMs. You might have a different strategy for this depending on the speed of connection between virtualized hosts, the uptime requirements of the virtual machine and the need for pre-production testing.

Major considerations in the V2V migration process include:

  • Image file formats - Many virtualization platforms offer support for multiple image formats. The performance and portability of these vary. You need to consider the efficiency of the target image format as well as the complexity of the conversion process.
  • Live virtual machine - the ability to migrate a VM from a live cluster to a new target cluster is very attractive. Instant feedback on the success of the migration and a reduction in the downtime are required. This type of migration however is most sensitive to network latency and or performance/load on the virtualization infrastructure. This type of migration is optimal for VMs that are small and have light resource usage.
  • Disk based migration - migration of VM images from local storage to the target virtualization infrastructure provides the quickest conversion performance. It allows for test runs and other pre-production processes to be completed before embarking on the final migration process. Attention needs to be paid to downtime of the production VM and also in the copying of the disk image from the source to target VM clusters.

I hope that you find the above tips helpful to your organization. In my next blog, we will explore the RHEV 3.6 virt v-2-v tool that enables administrators to migrate their vSphere workloads into Red Hat Enterprise Virtualization.