Migrate VMs on KVM CentOS 5 to CentOS 6

Introduction to KVM Migration

This procedure is for Abiquo 2.4 to migrate KVM VMs from CentOS 5 to the compatible version of CentOS 6. This procedure does not include upgrading or installing Abiquo AIM.

Abiquo CentOS Version Compatibility Table

Abiquo VersionCompatible CentOS versionAIM version requiredNotes
2.45.x or 6.3.x1.5.3Migration to CentOS 6.3 can be performed separately from the upgrade to Abiquo 2.6 but an additional VM power off for CentOS 6.4 upgrade will be required.
2.66.4.x / 6.3.x2.1.4Migration to 6.4.x can be performed directly together with the upgrade to Abiquo 2.6.

This procedure was tested with two Abiquo KVM nodes running on CentOS 5. The procedure uses non-live VM migration between CentOS 5 hosts and a CentOS 6 hosts. Note that you cannot migrate the operating system. This procedure requires a downtime window and additional KVM servers. 

 To run Abiquo 2.6, KVM hypervisors running on CentOS 6.3 must be upgraded to run on CentOS 6.4, with the new version of Abiquo AIM and the appropriate modifications to the VM definitions.

  • You cannot use live migration to move from KVM on CentOS 5 to CentOS 6
  • This migration requires
    • Abiquo 2.4
    • 2 x Abiquo KVM nodes running on CentOS 5
    • At least 1 x Abiquo KVM node running on CentOS 6
    • Hypervisor downtime
    • A shared datastore may make the migration easier

Advantages of CentOS 6 for KVM Virtualization

This section summarizes the advantages of KVM on CentOS 6 over CentOS 5, as found on the Red Hat website.

The KVM hypervisor integrated into RHEL 6 (CentOS 6) offers many improvements over the previous version. These include tighter integration with the operating system and implicit benefits from core kernel features, as well as advanced paravirtualization features. Moreover, there have been major improvements in I/O performance, scalability and deployment flexibility. The new version enables users to deploy enterprise applications on a large scale in virtualized environments that incorporate the best features of physical and virtualized systems. Performance improvements to I/O systems have improved virtual system performance to near equal physical systems, which combined with greater consistency between physical and virtual environments enables IT departments greater choice of where to run. Interoperability improvements include greater support for Microsoft Windows guests, enabling rapid deployment and easy management of heterogeneous environments. Finally, scalability has increased to allow more memory and CPUs per guest and more guests per server.

General Advantages of CentOS 6 for Virtualization

This section is a summary of the Red Hat website of CentOS 6 over CentOS 5 that are especailly relevant for virtualization and cloud infrastructure platforms.

FeatureExample
Performance
  • Flush daemons for each LUN substantially improve performance of enterprise applications running with large I/O subsystems
Client/Desktop
  • VDI/HVD capabilities enable centralized hosting of both Microsoft Windows and Red Hat Enterprise Linux desktops
Scalability
  • Red Hat Enterprise Linux 6 scales to the largest systems available today and should scale well for new systems over ten years
    • Virtual guests are also highly scalable
Green IT
  • Features, tools and APIs have been enhanced to reduce the power usage of machines running Red Hat Enterprise Linux 6
High Availability
  • Red Hat Enterprise Linux 6 takes advantage of new hardware capabilities to offer improvements in Reliability, Availability and Serviceability.
    • E.g. hot add of devices and memory, and enhanced error checking for PCIe devices

  • Recovery from hardware errors using MCA (Machine Check Architecture) capabilities

  • Support for advanced SCSI data integrity features – DIF (Data Integrity Field) and DIX (Data Integrity eXtension)

Resource Management
  • Control Groups (cgroups)
    • Generic framework for plug-in controllers that manage resources such as memory, scheduling, CPUs, network traffic and I/O
    • Allocate processor, memory and I/O resources among applications and virtual guests
      • Fine grained control of resource utilization of physical and virtualized environments
        • Memory consumption, I/O utilization and process priority
          • Policies for QoS
Security
  • Security
    • Svirt 
      • Isolates and contains virtual guests
      • Users can confidently perform Live Migration of virtual guests across systems or deploy in the cloud
        • Prevents malicious adjoining guests from violating security
    • Others: Xace, Sandboxing, Kiosk, Policykit
Identity and Authentication
  • Identity and Authentication
    • Client systems can authenticate against multiple environments
      • Microsoft Active Directory, LDAP, Red Hat Directory Server, Kerberos, and IPA
      • Supports multiple identity domains/disconnected users
Networking
  • Networking includes
    • IPv6 mobility and other enhancements for RFCs
    • UDP-lite for VoIP, etc.
    • Congestion control algorithims
    • Various performance improvements
    • Datacenter briding support with 802.1p/802.1Qaz
    • Updated kernel subsystems for NFS/CIFS/RDMA
Filesystems and Storage
  • Filesystems and Storage
    • Ext4 - stability with improved scalability (up to 16 TB) and performance
    • XFS - for larger, specialized environments with high-end servers and storage arrays
    • GFS2 - high-availability clusters with 2-16 nodes, including clustered Samba
    • LVM - online resizing of mirrored volumes and snapshot rollbacks
    • Storage topology awareness enables software to determine the best I/O blocking patterns from the hardware
Interoperability
  • Microsoft Windows support includes:
    • Latest version of Samba 
    • IPv6, Windows 2008 (R2) trust relationships, Windows 7 domain members, and Active Directory LDAP signing/sealing policy. 
    • Windows cross-forest, transitive trusts and one-way domain trusts
    • Windows management tools (mmc and User Manager)

Preparation

The following diagram gives an overview of how to prepare for the KVM CentOS 5 to CentOS 6 migration.

Install KVM on CentOS 6

To save downtime and resources, install CentOS 6 on as many machines as possible.

Ideally, to migrate each machine, you will have spare capacity to move all the virtual machines on a CentOS 5 server to a CentOS 6 server that is installed on the same Abiquo rack.

Commence the migration by using allocation rules to ensure that new virtual machines deploy to CentOS 6 servers as described in the following section.

Send new deployments to CentOS 6 using Allocation Rules

Create a strategy using the methods described in this table. 

MethodStepsComments
Set deploys to
machine with most free capacity
  1. Remove overscubscription by Load Level for CPU on CentOS 5
  2. Set Load Balance to PERFORMANCE
  • New deploys will go to CentOS 6 until usage exceeds the CentOS 5 server usage
  • Users can reconfigure and undeploy
Restrict available CPU and RAM
  1. Set Load Level to 1% CPU and 1% RAM
  • This will block all deploys to CentOS 5
  • Users cannot reconfigure VMs

If you migrate a group of virtual machines during downtime, you can also disable the CentOS 5 physical machine in Abiquo.

Virtual Machine Migration

Prepare VMs for Migration

Check that virtual machines are ready for migration. Back up VM disks and notify users.

Confirm which CentOS 5 hypervisor hosts each of the VMs.

Dump the XML Configuration of the VMs to Migrate

Log in to the CentOS 5 hypervisor and create a backup of the XML configuration of the VMs to migrate.

For example, you could use the following shell command.

for vm in $(virsh list --all | sed '1,2d' | awk '{print $2}'); do echo $vm; virsh dumpxml $vm | tee "$vm.xml" | grep "source file\|source dev"; done

This will:

  • list the names of all VMs
  • dump their XML configurations to files ending in .xml in the current directory 
  • list all the disks (hard disks on datastores and iSCSI volumes attached)

Output of the shell command for two VMs. The source files are the template

[root@localhost ~]# for vm in $(virsh list --all | sed '1,2d' | awk '{print $2}'); do echo $vm; virsh dumpxml $vm | tee "$vm.xml" | grep "source file\|source dev"; done
ABQ_0994a1e3-8afa-40ef-b27d-d8265db977ef
      <source file='/var/lib/virt/ABQ_0994a1e3-8afa-40ef-b27d-d8265db977ef'/>
ABQ_aca3f24c-cfd0-455a-9621-b7725b3c04c2
      <source file='/var/lib/virt/ABQ_aca3f24c-cfd0-455a-9621-b7725b3c04c2'/>

Power Off the VMs to Migrate

Power off VMs to be migrated.

Undefine the VMs on the Hypervisor

Log in to KVM on CentOS 5 and undefine the VMs.

For example, using virsh:

# cd /var/lib/virt
# virsh
 
virsh # list --inactive 
 Id Name                 State
----------------------------------
  - ABQ_0994a1e3-8afa-40ef-b27d-d8265db977ef shut off
  - ABQ_aca3f24c-cfd0-455a-9621-b7725b3c04c2 shut off
 
virsh # undefine ABQ_0994a1e3-8afa-40ef-b27d-d8265db977ef
Domain ABQ_0994a1e3-8afa-40ef-b27d-d8265db977ef has been undefined


virsh # undefine ABQ_aca3f24c-cfd0-455a-9621-b7725b3c04c2
Domain ABQ_aca3f24c-cfd0-455a-9621-b7725b3c04c2 has been undefined

Check VMs Are Undeployed in Abiquo

Check that Abiquo set the virtual machines as undeployed.

Rename VM Disks

To save the VM disks, rename them.

First, log in to the hypervisor running on CentOS 5, change to the datastore directory (by default /var/lib/virt) and list the virtual machine disks to migrate. 

Move these virtual machine disks to files with a different name.

For example if a VM's disk is located in /var/lib/virt/ABQ_5ad3c016-c361-4bc4-9a64-6cb3ce854ac7, then move the disk to /var/lib/virt/ABQ_5ad3c016-c361-4bc4-9a64-6cb3ce854ac7_BACK.

Ensure Abiquo Will Deploy to CentOS 6 

In Abiquo, prevent deployment to the physical machine(s) running KVM on CentOS 5. If you are migrating VMs during system downtime, you can disable the CentOS 5 machines.

Ensure that when you redeploy the VMs that were running on the CentOS 5 server, they will go to one of the new servers.

VM Replacement

If you do not rename the original VM disks and ensure that VMs are deployed to the CentOS 6 servers, the virtual machine may be overwritten with a new copy of the template disk, and user changes will be lost.

Deploy the Virtual Machines

Deploy the virtual machines with Abiquo.  Check that Abiquo has successfully deployed to the CentOS 6 hosts.

Before handing over the migrated machines to the cloud users, you need to replace their disks with the ones you renamed earlier.

Power off the Newly Deployed Virtual Machines

Power off the newly deployed virtual machines in Abiquo.

If Necessary, Copy the Old VM Disks to the New Hypervisor Datastore

If you are not using a shared datastore, or the virtual machines have been deployed to a different datastore, copy the disks of the old virtual machines to the location where the new virtual machines have deployed.

Remove the New VM Disks

Remove the NEW disks 

Replace the New VM Disks with the Old VM Disks

Move the old VM disk files into place to run with the new VM definitions.

Start the Virtual Machines in Abiquo

Start the virtual machines in Abiquo. Check that the virtual machines start up properly. You can now delete the _BACK files on the CentOS 5 system. Note that on the hypervisor, after you start the virtual machines, in the operating system the owner of the disk files is now qemu. Repeat until all your infrastructure is running on CentOS 6 servers. If any of your CentOS 5 servers empties, you can reinstall it as a Centos 6 to give you more resources for the migration.


Unable to render {include} The included page could not be found.