CloudOpen – Seattle 2015

Clone existing VMs to CloudStack/OpenStack templates without user downtime

Transparent Service Migration to the Cloud

#whoami

Name: Tim Mackey

Current roles: XenServer Community Manager and Evangelist; occasional coder

Cool things I’ve done • Designed laser communication systems

• Early designer of retail self-checkout machines

• Embedded special relativity algorithms into industrial control system

Find me • Twitter: @XenServerArmy

• SlideShare: slideshare.net/TimMackey

• LinkedIn: https://www.linkedin.com/in/mackeytim

• GitHub: https://github.com/xenserverarmy

Define “VM Migration”

What people think • VM moves from source host to destination

Why it doesn’t work “to the cloud” • Incompatible host micro-architecture

• Lack of control over networking

• Do we really want a VM_HALT?

• Long distance ARP

Really need “template migration”

Template

Template

Template

CloudStack view of Templates

Template Management in CloudStack

My first template • Existing VM or appliance in VHD format – compression optional

• Need to have HTTP server

• Set secstorage.allowed.internal.sites if private cloud

Creation options • Register template in UI

• Templates Register Template

• Upload using registerTemplate API

• http://cloudstack.apache.org/docs/api/apidocs-4.5/user/registerTemplate.html

• Clone from CloudStack instance

• Stop instance View Volumes Create Template

Key Template Attributes

Obvious • Hypervisor

• Operating system type

• Zone

Not so obvious • IsDynamicallyScalable Hypervisor tools

• PasswordEnabled CloudStack sets root pwd

• SSHKeyEnabled Can post configure

• RequiresHVM Defines virtualization mode

VM Password and SSH Key Management Challenges

Obtain information from Virtual Router • IP is obtained from leases

• Scripts use wget

• Assumes sysinit not systemd

What to fix – varies by OS? • CentOS 7 defaults to curl not wget

• CentOS 7 is systemd need unit files

• CentOS 7 may use NetworkManager

OpenStack view of Templates

Template Management in Horizon and Glance

My first template • Existing VM or appliance in hypervisor specific disk format

• XenServer: VHD format with file named 0.VHD and tgz

Creation options • Register image in Horizon

• System->Images->Create Image

• Upload using Glance API

• http://docs.openstack.org/developer/glance/glanceapi.html

• Clone from running instance

• Compute->Instances->Create Snapshot

Key Image Attributes

Obvious (x-image-meta-) • Owner

• Flavor information (Disk and RAM)

• Region

Not so obvious (x-image-meta-property) • hypervisor_type Xen for XenServer

• vm_mode PV vs. HVM

• os_type Linux or Windows for swap space

Handling Critical Initial VM Configuration

Obtain information from instance configuration drive • ISO 9660 or VFAT drive assigned to instance at boot

• Supported with libvirt, XenServer, vSphere and Hyper-V

• Works with custom scripts and cloud-init

Using a configuration drive • Specify per instance on nova boot --config-drive true

• Force for all instances in nova config force_config_driver=true

• Pass both meta information and userdata

How the tooling works

Packer is Awesome!! http://packer.io

Core Packer Concepts

Builder • Responsible for creation of VM image

• Connects to virtual infrastructure

• Default supports vSphere, OpenStack, AMI, VirtualBox, QEMU, Docker

• No XenServer needed to fix that ;)

Provisioner • Runs post-build activities

Post-Processor • Takes VM image artifact and transforms it

• In our case upload to CloudStack or OpenStack needed to fix that too ;)

Key Activities Occurring During Template Build from ISO

1. Download ISO into ISO SR (if not already present)

2. Attach ISO to VM object and boot

3. Instruct installer to user kickstart file

4. Installer does its thing and shuts VM down

5. Upon shutdown, swap installer ISO for XenServer tools ISO

6. Install ISO and shutdown

7. Detect shutdown and run Provisioners

8. Export and import into the cloud as template

xenserver-iso builder

Creates a new XenServer image from an ISO

Key parameters • Host connection

• ISO location

• Boot commands

Artifact output type • xva, vdi_raw, vhd, vhd_raw

Known limitations • Linux only (uses SSH)

• Requires NFS shared storage for export

xenserver-vm builder

Creates a new XenServer image from existing running VM

Key parameters • Host connection

• VM name

• Cleanse command

• Cleanse scripts

Artifact output type • xva, vdi_raw, vhd, vhd_raw

Known limitations • Linux only (uses SSH)

• Requires NFS shared storage for export

cloudstack-xenserver post-processor

Creates a new CloudStack template from xenserver builders

Key parameters • CloudStack API keys

• Zone, OS type

• Script configuration

Artifact input • xenserver-iso, xenserver-vm

openstack-xenserver post-processor

Creates a new OpenStack Glance image from xenserver builders

Key parameters • Keystone URL and credentials

• Project name, region, and instance name

• Script configuration

Artifact input • xenserver-iso, xenserver-vm

Key Activities Occurring During Service Migration

1. Snapshot of existing VM to minimize downtime

2. Detect if VM is PV or HVM and flag accordingly

3. Copy snapshot to NFS SR to collapse any snapshot chains

4. Connect primary network to HIMN to ensure no machine collision

5. Use VNC to reconfigure network and connect to XenServer DHCP server

6. Copy and run cleanse scripts which shutdown clone when complete

7. Detect shutdown and run Provisioners

8. Export and import into cloud as template

10 minutes to move a live service to the cloud (network willing) …

Demo time ….

The Service to Migrate – Piwigo http://piwigo.org

The Original Topology

The Cloud Topology with Original Data Store Intact

My Cloud

Bringing “Migration” all Together with an ADC

Users

Confirm the Migration and Iterate

1. Verify service migrated correctly

2. Iterate and resolve any issues

3. Scale the service • Let’s add more capacity

4. Add service to original load balancer • Don’t forget to adjust session weights

5. Decommission original service

Questions?