►
Description
KubeVirt opens scenarios for a Kubernetes based infrastructure that can handle both VMs and containers. Wouldn't it be great to just automatically move all your Virtual Machines from legacy environments and consolidate your whole infrastructure around Kubernetes and KubeVirt?
Coriolis performs automated migrations among most common clouds and virtualization solutions, like VMware, OpenStack, AWS, Azure, AzureStack, OCI, Hyper-V and now also KubeVirt.
During this session we will perform a live demo showing how to migrate a VM from VMware vSphere to KubeVirt and a separate demo showing the migration of a VM from OpenStack to KubeVirt.
Presenters:
- Alessandro Pilotti, CEO/CTO, Cloudbase Solutions, @cloudbaseit, https://github.com/alexpilotti/
- Gabriel Samfira, Cloud Architect, Cloudbase Solutions, @gabriel_samfira, https://github.com/gabriel-samfira
A
B
B
B
B
A
We
will
show
you
a
couple
of
things
so
first
I
will
run
a
few
slides
just
to
set
a
little
bit
of
the
context.
What
coriolis
is
how
cloud
migrations
work
and
so
on,
and
then
again
we
will
will
continue
with
that
awesome
demo,
okay,
so
a
little
bit
on
the
context.
The
main
idea
is
that
we,
you
know
in
our
history,
working
in
clouds,
the
first
with
openstack
and
with
kubernetes
and
so
on.
We
saw
that
customers
and
users
are
always
all
the
time
moving
between
different
generations,
you
know
or
for
fighting
infrastructure.
A
You
know
moving
from
physical
service
to
vm
infrastructure
as
a
service,
then
containers
now
serverless
and
so
on.
So
what
we
really
liked
with
the
kubert
project
was
the
the
idea
of
bridging
that
gap
between
vms
and
containers.
You
know
so
there
are
two
different
generations
in
this
journey
across
infrastructure.
If
you
want,
and-
and
you
know,
we
ended
up
in
a
way
in
having
like
people
running
vms,
typically
either
on
openstack
or
on
vmware
or
whatever
else
you
know,
and
then
I
have
a
completely
different
infrastructure
for
running
containers.
A
A
Workloads
can
spawn
across
vms
and
containers,
sharing
resources,
like
you
know,
sharing
the
same
networking,
resources,
storage,
pves
and
so
on,
and
also
very
important.
This
way,
customers
can
just
get
rid
of.
I
mean
users
can
get
rid
of.
You
know
their
legacy
platform,
so
you
don't
need
to
have
your
traditional
vmware
stack.
You
know
there
just
to
keep
running
games
when
you
can
run
everything
all
together.
So
that's
very
important
in
order
to
reduce
the
time
that
you
need
to
onboard
on
on
a
new
technology
or
a
new
platform.
A
When
we
talk
about
migration,
okay,
it's
a
relatively
complex
topic,
but
let's
say
that
we
can
reduce
it
for
now
to
two
very
simple
points:
one
of
them
is
lift
and
shift
in
which
we
take
vms.
We
consider
them
like
black
boxes
and
we
move
them
from
a
to
b,
let's
say
from
whatever
infrastructure
they're
running
at
the
moment
to
cube
word
as
we're
talking
about
arena.
A
This
is
great
for
legacy.
Applications,
linux
or
windows
doesn't
really
matter,
because
you
know
it's
it's
it's
much
easier.
You
don't
have
to
deal
with
all
the
complexity,
the
fact
that
they
might
not
be
containerized
in
and
and
the
fact
that
you
simply
might
not
know
how
to
handle
them
outside
of
a
vm
scenario.
A
One
big
advantage
of
lifter
shift
is
that
it
can
be
fully
automated
on
the
opposite
side.
We
have
re-platforming
or
containerization.
If
you
want
in
this
case,
which
it's
great,
but
it
cannot
be
fully
automated
meaning
that
you
typically
have
to
look
into
each
individual
workload,
understanding
you
know
which
services
are
needed
with
processes
put
those
into
containers,
whitening,
docker
files
and
yada
yada,
okay,
and
it
doesn't
really
work
for
all
legacy
workloads,
unlike
lift
and
shift
which,
since
it
doesn't
care
about
you
know,
what's
inside
of
those
vms,
makes
everything
much
easier
for
that.
A
From
that
point
of
view,
so
lifter
shift
sounds
easy,
but
in
reality
it's
quite
complex
per
se.
First,
you
have
to
deal
with
virtual
different
virtual
disk
formats,
which
is
the
easiest
of
those
points
you
know.
For
example,
if
you
come
from
vmware,
you
typically
have
a
vmdks,
while
you
know
running
on
something
like
kvm
bit
up
with
two
emo
you'd
end
up
without
error
profile
so
or
qcal2
or
whatever
you
know.
A
So
virtual
yo
4kvm,
you
can
have
vmware
tools,
of
course,
for
for
your
6i.
You
have
lis
on
on
hyper-v
and
so
on.
Then
you
might
have
to
rebuild
the
uni3d
images,
because
you
need
different
current
modules
that
need
to
start.
You
need
to
run
when,
when
the
camera
boots,
you
have
sc
linux,
of
course,
as
linux,
will
we
see
that
there
is
a
completely
different
underlying
hardware
and
obviously
freak
out
and
tell
you
well,
you
cannot
run
right
now,
because
somebody
changed
radically
everything
right
now.
A
You
have
different
pci
ids,
which
also
means
dealing
potentially
with
different
network
configurations,
and
then
you
have
also
different
provisioning
agents.
For
example,
if
you
move
to
cubework,
you
might
need
to
run
a
cloud
inita
cloud
business.
You
know
in
asia,
you
might
have
something
like
the
azure
library,
linux,
agent
and
so
on.
So
all
those
things
need
to
be
taken
into
account.
A
Coriolis
was
the
project
that
we
created
exactly
for
that.
The
idea
is
to
do
fully
automated,
lift
and
shift
migration
from
and
to
any
cloud
virtualization
solution.
It
has
to
be
scalable,
it
doesn't
matter
if
you
do
one
or
a
thousand
migrations
at
a
time.
It
just
has
to
work,
of
course,
in
the
limits
of
what
your
physical
infrastructure
is.
It's
agentless,
and
this
is
very
important,
meaning
that
you
don't
have
to
run
anything
inside
of
the
actual
vms
and
the
vms
actually
can
still
run.
There
is
no
reason
to
stop
the
vms.
A
While
this
work
is
in
progress,
the
migration
is
in
progress.
It
has
a
rest
api
for
full
automation,
it
have
a
graphical
user
interface,
a
web
app
a
web
interface
and
a
command
line.
One
both
of
them
sit,
of
course,
in
front
of
the
rest,
api
and
very
important,
the
architecturally,
fully
decoupled
from
individual
cloud
virtualization
solutions.
That
means
that
when
we
add
support
for
new
ones,
it's
relatively
simple
and
we
don't
need
to
touch
actually
the
core
of
kubernetes
itself.
Here
is
a
quick
intro
on
the
architecture
you
can
see.
A
There
is
a
on
top
of
course
there,
the
clients,
then
you
have
the
rest
api.
You
have
a
conductor
where
pretty
much
all
the
logic
stays
you
have
a
scheduler
which,
as
name
implies,
is
in
charge
of
scheduling
and
then
very
important.
You
have
the
workers,
which
are
the
ones
which
are
going
to
talk
to
the
individual
clouds.
A
We
use
a
couple
of
openstack
projects
here,
keystone
for
identity
and
barbican,
for
storing
secrets
secrets,
meaning
that
when
we
get
cadential
to
access
source
and
target
clouds,
we
do
need
to
share
them
in
clear
tax
accounts
across
the
whole
stack.
We
just
store
them
in
barbican
and
we
retrieve
them
and
the
worker
processes
just
retrieve
them
when
it's
time
to
to
talk
to
the
individual
clouds.
A
All
those
are
basically
micro
services.
They
talk
among
each
other,
with
mqp
can
be
easily
containerized.
And
again
we
come
from
a
background
of
cloud
builders,
meaning
that
we
we
contributed
a
lot
to
both
openstack.
We
work
a
lot
in
kubernetes,
so
it
was
written
like
like
a
cloud
service.
Basically,
okay,
I'm
going
quickly,
because
I
want
to
get
to
the
demo
as
fast
as
possible,
supported
cloud
and
virtualization
solutions.
A
A
That
means
basically
talking
about
kubert
that
you
can
basically
migrate
your
vms
from
pretty
much
any
of
those
source
environments.
So
you
have
vms
on
aws,
no
problem.
You
can
migrate
them
to
keyboard.
You
have
the
manager
same
so
this
we
limited,
of
course,
this
particular
session
to
to
openstack
and
and
and
vmware
for
the
simple
reason
we
don't
have,
the
time
to
to
demo
all
of
them,
but
the
same
concepts
that
we're
going
to
to
demo
apply
to
them
to
all
those
those
clouds
and
recreational
solutions.
A
We
attach
basically
the
volumes
in
which
we
pre-replicated
all
the
content
of
the
vms
of
the
disks
that
are
attached
to
the
vms,
and
we
discover
what
type
of
os
type
and
digital
we
have,
and
then
we
take
some
specific
actions
which
are
specific
to
those
environments,
for
example
adding
virtual
drivers
adding
cloud
in
it
and
whatever
else,
okay,
on
the
on
the
supported
guest
operating
system.
Also,
here
the
support
for
the
guest
is
fully
decoupled
for
the
core
of
the
project.
A
A
When
we
started
this
project
originally
it
was
meant
for
migrations,
and
then
people
started
a
lot
about
hey.
Can
I
also
use
it
for
disaster
recovery,
so
this
is
a
feature
that
we
added
and
fits
very
well
in
the
way
in
which
coriolis
works,
corollas
introduces,
of
course,
the
disaster
recovers
as
a
service
feature,
we
call
it
replica
and
if
the
source
cloud
allows
it,
which
happens
most
of
the
time
without
entering
into
details
right
now,
data
is
backed
up
incrementally
to
the
target,
while
the
vm,
the
source
vm,
is
still
running.
A
A
If
you
want,
you
can
keep
on
replicating
the
content
on
the
target
and
then,
if
disaster
strikes,
you
can
anytime
simply
start
the
machines
on
the
target
environment,
because
that
is
the
the
way
which
in
which
migration
works
and
most
important
all
the
inputs
right
on
the
target
in
kubernetes.
In
this
case,
so
you
don't
need
to
have
access
to
the
source.
A
Another
thing
that
we
insist
always
a
lot:
you
know
migration
across
two
completely
different
environments
like
vmware,
openstack,
openstack
on
one
side
and
keyword
on
the
other
might
hide,
of
course,
some
surprises.
So
they,
the
main
idea,
is
that,
thanks
to
the
replica
mechanism,
you
can
anytime,
basically
out
of
those
replicas,
create
some
migrations
test
that
everything
works.
Fine
manually,
part
of
uk
procedures,
continuous
integration,
testing
whatever
and
and
then
only
when
you
need
you
can
actually
finalize
those
migrations
and
put
them
into
production.
A
Okay,
so
those
are
also
very
useful
and
that
helps
us
a
lot
when
your
workload
is
not
made
by
a
single
vm
but
a
lot
of
different
vms.
Maybe
it
could
be
a
database,
it
could
be.
I
don't
know
a
front
end
with
a
web
app,
some
middleware
or
whatever
else.
So
you
want
to
make
sure
that
all
the
connectivity
among
them
works
fine.
A
And
since
we
talk
about
hubert,
you
might
also
want
to
make
sure
that,
for
example,
some
additional
kubernetes
ports,
which
connect
maybe
to
the
to
services
exposed
on
those
vms,
might
work
as
well
as
expect,
okay,
so
time
for
our
demos.
So
I
will
switch
to
my
colleague,
gabriel.
That
will
continue
with
the
depths.
Thank.
D
D
D
Both
of
these
will
be
migrated
in
a
live
demo.
Hopefully
the
demo
gods
are
not
angry
today.
So,
let's,
let's
get
right
into
it.
We'll
migrate
this
to
a
cube,
vert
deployment.
This
is
a
plain
cube
view
deployment
on
top
deployed
with
cube
adm,
so
nothing
special
here,
cube
vert
is
enabled
so,
let's
get
to
the
demo.
D
This
is
corey
aldis.
This
is
the
login
screen.
The
first
thing
you
see
when
you
log
into
coriolis
is
a
simple
dashboard
where
you
get
a
sense
of
what's
going
on
inside
coriolis
itself,
so
you
get
a
list
of
recent
replicas
that
will
run
migrations,
endpoints
that
you
have
created
and
so
on
now.
The
first
thing
you
do
after
you
log
in
into
a
new
cordless
deployment,
is
you
need
to
add
some
endpoints
points
are
credentials.
D
You
give
to
corey
holders
to
access
your
source
and
destination
clouds
for
in
order
for
coriolis
to
be
able
to
migrate
instances
from
that
source
cloud
to
any
destination
that
we
support.
These
are
just
a
few
of
the
plugins.
We
support
most
of
them
actually,
but
they
will
appear
in
this
list
as
as
you
enable
them
inside
coriolis.
D
D
You
just
give
it
to
coriolis
for
coriolis
to
be
able
to
access
your
cube,
very
deployment.
You
click
validate
and
save
and
correlates
will
go
out,
connect
to
kubernetes
check
that
the
crd
is
there
and
if
it's
there,
it
will
give
you
that
green
check
mark.
You
saw
briefly,
and
you
get
an
end
point
here.
You
can
use
to
ingest
your
instances.
D
I
also
have
a
couple
of
open
openstack
endpoints
and
an
esxi
6
endpoint
that
you
see
here
so
as
soon
as
you
have
all
your
endpoints
set
up,
all
you
have
to
do
is
go
to
replicas
now,
like
alessandra,
said
right
because
our
disaster
recovery
as
a
service
implementation.
You
can
also
have
simple
migrations,
which
are
a
one-off,
where
you
do
both
the
the
sync
of
the
data
for
your
instances,
as
well
as
the
final
migration
in
one
operation.
D
Replicas
are
split
into
you,
get
to
sync
your
disk
data
repeatedly
and
not
do
the
actual
migrations.
If
you
don't
want
to
only
commit
to
doing
the
migration
when
disaster
strikes
in
your
source
cloud
is
no
longer
accessible,
but
if
you
just
want
to
migrate,
you
can
use
simple
migrations
now
to
create
a
new
replica.
You
go
to
new
replica
here,
you
get
a
toggle
if
you
want
to
switch
between
normal
migrations
and
replicas
we're
going
to
go
with
replicas
today,
click
on
next,
you
select
your
source
cloud.
D
D
Here
you
get
the
option
to
automatically
enable
cbt
snapshots
for
the
instances
you
are
about
to
migrate.
Now
you
want
to
do
this
because
cbt
will
allow
us
to
do
incremental
replicas,
basically
diffs
from
replica
run
to
replica
run
and
we'll.
It
also
allows
us
to
if,
if
in
the
provision,
only
transferred
written
blocks
on
the
vmdks
that
are
part
of
the
instance
we're
about
to
migrate,
so
click
next.
D
D
I
realize
the
text
is
small.
This
web
interface
does
not
really
allow
you
to
resize
it,
but
essentially
I
created
a
file
with
a
timestamp
and
some
text.
Inside
now
we
go
back
to
coriolis.
We
click
next,
oh,
and
you
can,
of
course,
migrate
multiple
instances
as
a
group.
So,
for
example,
if
you
have
a
cluster
of
servers
that
you
would
like
to
migrate
all
at
once,
you
can
do
that.
We're
just
going
to
go
with
one
for
now
and
we
want
to
migrate
to
cubejerk.
D
The
cluster
name,
we
generate
a
bunch
of
certificates
that
we
use
to
communicate
with
the
components
we
spawn
in
kubernetes
to
ingest
that
the
actual
disk
data.
We
have
a
small
application
that
allows
us
to
stream
the
disk
data
from
your
source
provider
from
your
source
cloud
to
cube
vert
inside
a
physical
volume
that
will
be
setting
up
automatically
the
namespace,
where
you
want
this
to
end
up
we're
just
going
to
go
with
the
default
namespace.
D
You
click
next
here
now.
Coriolis
traditionally
will
allow
you
to
specify
a
mapping
between
source
network
and
destination
network.
We
only
have
one
network
in
and
this
kubernetes
deployment,
but,
of
course,
if
you
have
multis
enabled-
and
it
allows
you
to
create
multiple
networks,
you
can
choose
which
network
you
would
like
this
instance
to
end
up
in.
D
So
this
is
a
mapping
between
source
network
and
destination
network,
for
example,
if
vm
network
network
on
a
vmware
esxi
corresponds
to
a
different
network
in
your
kubernetes
deployment,
here
is
the
place
where
you
you
can
map
that
click.
Next
same
thing:
for
storage,
you
get
a
listing
of
all
the
disks
that
you
have
enabled
for
this
particular
vm.
We
only
have
one
here,
but
you
can
choose
with
various
granularity
levels
where
your
storage
will
end
up.
D
So
the
default
storage
can
be
one
of
the
storage
classes
in
your
cluster
or
you
can
map
a
whole
data
store
from
esxi
to
one
of
the
storage
class
classes
or
individual
disks.
We're
just
gonna
we're
just
gonna
go
with
the
rbd
one
click
next
here
you
have
the
option
to
specify
any
additional
customization
scripts.
These
are
essentially
bash
scripts
or
python
scripts
or
whatever
kind
of
scripts
will
work
on
common
linux
instances
or
powershell
for
windows.
D
This
will
allow
you
to
make
any
last
minute
changes
of
your
instance,
while
it's
being
migrated,
migrated
like
adding
users
changing
files
and
so
on
click.
Next,
here
you
can
add
a
chrome-like
schedule
like
like
we
said
replicas
allow
you
to
do
incremental
syncs
of
your
instance
without
committing
to
migrating
it.
Necessarily.
D
D
That's
been
selected
so
far,
click
finish
and
when
we
do
that,
coriolis
will
create
a
set
of
tasks
that
will
take
care
of
replicating
the
disk
data,
fetching
the
metadata
about
the
instance
from
from
your
source
and
making
sure
that
you
get
a
one-to-one
copy
at
the
end
of
this
process
to
your
destination.
So
we're
now
validating
the
instance
information
we're
checking
the
cbt
status
of
the
instance.
D
And
this
is
the
disc
that
has
just
been
created:
it's
a
16
gigabyte
disk.
We
are
now
creating
a
bunch
of
pods
that
will
take
care
of
the
disk
sync.
This
a
particular
pod
which
has
just
been
spawned,
will
ingest
the
disk
data
from
your
source
and
here
we're
doing
a
full
cpt
snapshot
the
disk
and
is
a
total
of
16
gigabytes,
but
only
around
1.8
gigabytes
of
data
are
written,
so
this
operation
should
be
quite
quick
as
this
syncs.
Let's
also
click
kick
off
a
sync
of
the
bionic
vm
from
openstack.
D
A
D
Okay,
all
right,
so,
let's
go
to
the.
I
already
have
a
precinct
replica
of
that
that
particular
instance
we're
just
going
to
execute
it.
So
I
did
a
sink
of
this
already,
but
this
will
show
how
we
replicate
the
deltas.
Only
a
small
bit
of
information
will
be
replicated
from
source
to
destination
in
this
particular.
D
The
centos
one
is
already
done
so,
while
the
other
one
syncs,
let's
migrate
this
one.
Now
at
this
point,
you
have
a
one-to-one
copy
of
your
instance
from
source
to
destination.
You
have
all
the
disk
data
in
your
kubernetes
cluster.
All
you
have
to
do
now
is
create
a
migration
from
it.
So
we
have
the
metadata
at
this
point.
If
your
source
cloud
goes
down,
you're
fine,
we
are
going
to
do
os
morphing
for
this
instance,
because
we're
moving
from
a
foreign
hypervisor
in
this
case
vmware
to
kvm
based
openstack.
D
D
Popup
should
here
we
go
view
migration
status
and
the
these
are
the
set
of
tasks
that
will
make
sure
that
this
instance
will
properly
boot
inside
cube
vert.
So
what
this
will
do
now
is
create
a
set
of
snapshots
from
the
disks
that
were
already
created
now,
if
you're
back
and
support
snapshots,
it
will
do
that.
If
not
it's
going
to
be
a
no
op.
D
D
This
is
a
temporary
instance
to
which
we
attach
the
disks
of
the
instance
we're
migrating
and
we'll
do
a
set
of
operations
on
those
disks
that
were
detailed
by
alessandro
in
the
slides,
where
we
installed
any
needed
drivers
and
make
any
changes
to
the
actual
disk
run.
Your
customization
scripts
that
you
can
optionally
set
to
do
last
minutes
last
minute
changes
and
so
on.
Once
this
process
is
done,
your
instance
will
boot
up
in
in
our
cube
vert
as
if
it
were
always
part
of
cube
verb.
D
So
here
we
see
we're
connected
to
connecting
to
the
temporary
worker.
It's
the
same
ip.
You
see
here
we're
discovering
the
the
partitions
that
we
need
to
look
at
and
during
os
morphing
we
also
enable
serial
console.
So
you
can
actually
connect
the
serial
console
to
your
to
your
instance.
We're
removing
any
superfluous
packet
packages.
We
don't
no
longer
need
open.
Vm
tools,
for
example,
is
of
no
use
on
kvm.