Migrating workloads from VMware to

OpenStack

Alessandro Pilotti | CEO @ Cloudbase Solutions

Agenda

+ Migration strategies

+ Coriolis

+ Migrations

+ Replicas / DRaaS

+ Demo

+ Workload testing / validation

The context

+ Companies move to the next dev / ops generation

+ Physical Servers -> VMs -> IaaS -> Containers -> Serverless

+ Rewrite LoB next gen applications while retaining investments on existing

generation

+ Improve TCO

Why migrating workloads?

+ In general: improved TCO

+ New on-prem cloud infrastructure

+ New on-prem hardware

+ On-prem to public cloud

+ Public cloud to on-prem

+ On-prem redeployment

What are the options?

Picture: Stephen Orban: buff.ly/2jZF5yv

Rearchitect

Pros

Apps become scalable

Apps become high available

Decoupling

Improved development and testing methodology (legacy spaghetti code -> CI/DC)

Cons

Expensive

Time consuming (most corporate legacy apps spawn across many years of development)

Users learning curve

Repurchase

Pros

No need to write it or mantaining yourself!

Typical example: move to a SaaS

Pay as you go

Cons

Customizations to fit the requirements

Data migration from can be expensive / time consuming

Users leaning curve

Retire

Pros

Retire unused software following an auditing

Cons

None, housecleaning is a good thing

Retain

Pros

Not everything can migrated or can be improved

Cons

Not everything can migrated or can be improved

Replatform

Examples:

Move apps to a PaaS, e.g. an ASP.Net site from a local IIS server to Azure Web Sites

Move a SQL Server database to OpenStack Trove

Wrap legacy apps in containers and deploy them via Kubernetes / Magnum

Wrap legacy apps in a PaaS (e.g. Azure Service Fabric on OpenStack)

Pros

Apps become at least partially scalable / high available without a full rewrite

Reduced footprint (no dedicated servers needed)

Cons

Lots of hacking involved and not all applications can fit this model

Rehost (lift and shift)

Move VMs or bare metal hosts to the new cloud

Examples:

VMware to OpenStack, AWS to Azure, AWS to OpenStack, etc

Pros:

Servers are “black boxes”, no need for changes

Fastest option

Cons:

Won’t take full advantage of cloud model (e.g. scalability)

Target cloud solution might not have host level HA, so HA might be lost from source environment

Lots of steps

+ virtual disk format

+ synthetic kernel drivers (VirtIO, VMware tools, LIS, etc)

+ initrd

+ SELinux

+ PCI ids / network configuration

+ Provisioning agents (cloud-init / cloudbase-init, Azure WALinuxAgent, etc)

More on rehosting

+ Easy when moving between homogeneous architectures / platforms

• e.g. OpenStack + KVM to OpenStack + KVM

+ Tricky when moving between architectures / platforms:

• e.g. VMware vSphere to OpenStack + KVM,

Introducing Coriolis – Migration as a Service

+ Fully automated lift-and-shift migrations from and to any cloud /

virtualization solutions

+ Scalable: do 1 migration or 1000 at a time

+ Rest API for full automation

+ Keystone identity management

Coriolis architecture

OpenStack components

+ Oslo.*

+ Keystone

+ Barbican

+ Swift

Supported clouds / virtualization solutions

+ OpenStack

• KVM, Hyper-V, ESXi, Xen

+ Azure

+ AWS

+ VMware vSphere

+ Hyper-V and SCVMM

+ XenServer

+ oVirt + KVM

+ Oracle VM

+ GCE (soon)

Task based execution

+ Tasks are actions executed sequentially or in parallel based on

dependencies.

+ Tasks are resilient for transient failures and atomic

+ Examples:

• http://paste.openstack.org/show/602940

• http://paste.openstack.org/show/jvUV17eFqQVf2fGCuwIT

• http://paste.openstack.org/show/OtO8QT4k71jkIMIAgf7g

OS morphing

+ Needed when a guest instance moves between different platforms and

architectures

+ A worker VM detects the OS type / distro

+ Actions specific to that OS and target platform are executed (e.g. add VirtIO

driver, add cloud-init, etc)

Supported operating systems

+ Debian 7+

+ Ubuntu 12.04+

+ SUSE SLE 11+

+ RHEL / CentOS / Oracle Linux 6+

+ Fedora

+ OpenSuse

+ Windows 7, 8, 8.1, 10

+ Windows Server 2008, 2008 R2, 2012, 2012 R2, 2016 (including Nano Server)

Coriolis REST API

Coriolis CLI

CLI is based on cliff, like the OpenStack client

migration cancel Cancel a migration

migration create Start a new migration

migration delete Delete a migration

migration list List migrations

migration show Show a migration

Coriolis CLI

replica create Create a new replica

replica delete Delete a replica

replica disks delete Delete replica target disks

replica execute Start a replica execution

replica execution cancel Cancel a replica execution

replica execution delete Delete a replica execution

replica execution list List replica executions

replica execution show Show a replica execution

replica list List replicas

replica show Show a replica

migration deploy replica Start a new migration from an existing replica

Coriolis GUI

+ Single page application

+ ReactJS

+ Open Source

What about downtime?

+ Coriolis introduces a DRaaS feature (disaster recovery as a service) called

replica

+ If the source cloud allows it, data is backed up incrementally to the target

while the source VM is running

+ Migration is performed as the last step directly on the target cloud

+ No need for the source VM to be available (useful in case of disaster)

How does it work?

+ Examples of backup technologies used:

• Cinder Backup

• VMware Change Block Tracking (CBT)

• Windows VSS (Hyper-V)

+ Some options like CBT and VSS allow app consistency

+ Stage 1: replica

+ Stage 2: migration

Coriolis DemoVMware to OpenStack

Validation and testing

+ Replica volumes can be snapshotted and duplicated to perform a test

migration

+ This allows fully automated Integration Testing to ensure the VMs work as

expected

+ Replica volumes are not changed: replicas can be executed in the meantime

+ Examples: test websites and databases

Get in touch

Twitter: @cloudbaseit

http://www.cloudbase.it/coriolishttp://ask.cloudbase.it

Questions?