►
From YouTube: Sponsored Session: Red Hat - Mass Migrate VMs to Kubernetes & Move Containers across Clusters at...
Description
Don’t miss out! Join us at our upcoming event: KubeCon + CloudNativeCon North America 2021 in Los Angeles, CA from October 12-15. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Sponsored Session: Red Hat - Mass Migrate VMs to Kubernetes and Move Containers across Clusters at Scale
Speakers: Miguel Pérez Colino, Fabien Dupont, John Matthews
See a demo for 2 of the 5 open-source tools that are part of the konveyor.io community. You'll see how you can mass migrate virtual machines to KubeVirt, how you can move containers across clusters – specifically OpenShift 3.11 to the latest version, a look into the other use cases the Konveyor community has developed tools for, and the new capabilities that will be developed.
A
Hello,
everyone-
this
is
miguel
perez
colino,
I'm
a
product
manager
in
red
hat,
I'm
working
in
the
conveyor
community
and
I'm
going
to
tell
you
about
conveyor,
and
I
want
to
tell
you
about
the
tools
that
we
are
using
and
my
colleagues
john
matthews
and
fabiendo
pond
are
going
to
do
a
couple
of
demos.
So
before
we
start,
let
me
introduce
you.
A
John
is
an
engineering
manager
that
is
working
in
container
migrations
with
the
migration
toolkit
for
containers
that
has
a
project
in
conveyor
called
crane
and
fabian
is
engineering
manager
for
forklift
that
has
a
downstream
version,
which
is
called
migration
token
fertilization
intended
to
move
virtual
machines
from
vmware
to
operative
visualization
to
convert
on
kubernetes.
So
let's
get
started
about
conveyor
next,
please
so
conveyor
is
a
project
community
in
which
we're
passionate
about
moving
workloads.
A
A
The
migration
took
for
applications
which
is
based
on
tackle
the
migration,
took
it
for
containers,
which
is
based
on
crane
and
the
migration
token
for
virtualization,
which
is
based
on
forklift.
Next,
you
could
see
these
projects,
as
we
say
first,
one
forklift
to
bring
host
to
virtual
machines.
Next,
we
have
also
crane
to
re-host
the
container.
A
Next
we
have
moved
to
cube,
as
I
already
mentioned,
to
replatform
next
tackle
to
refactor
applications,
java
applications
to
kubernetes
and
next
clerus
to
make
the
measurements
next,
and
this
is
completely
aligned
with
the
6r
framework
that
we
all
know
rehearsal
platform,
refactor,
retire,
retain
and
repurchase
that
everybody
is
using
right
now
to
modernize
their
workloads.
So
we
want
to
align
all
these
tools
to
all
these
cases.
A
So
whenever
you
want
to
do
rehost,
you
could
use
crane
or
forklift
when
you
want
to
do
the
platform
you
use
not
to
give
me
when
you
went
to
the
refractor
you
could
use
tackle.
So
today,
we're
going
to
see
crane
and
forklift
and
and
john
and
fabian
are
going
to
go
through
it
next,
and
this
is
it
next
now,
let's
see
the
forklift
demo
that
fabienne
is
going
to
do
fabian.
The
stage
is
yours.
A
B
B
What
we
try
to
achieve
is
provide
a
tool
that
allows
you
in
very
few
steps
to
move
a
lot
of
vms
directly
from
vmware
to
achieve
virtualization
or
convert,
and
all
you've
got
to
do
is
provide
the
source
and
destination
credentials,
map
infrastructure
and
create
a
migration
plan.
The
migration
panel
then
runs
and
your
vms
are
on
the
destination.
B
So
as
a
user,
the
first
thing
I
need
to
do
is
add
the
search
and
destination
providers
here
stores
in
vmware
destination
is
convert,
but
then
I
create
a
plan.
The
plan
is
linked
to
one
provider
cr
the
source,
because
we
all
all
go
to
convert.
Then
we
list
the
vms.
We
want
to
migrate,
so
we've
got
it
from
the
provider
inventory
and
then
we
do
the
mapping
of
the
search
and
destination
say
you
come
from
a
specific
data
store
on
vmware
site.
B
B
We
want
to
run
the
migration,
so
we
click
or
we
create
a
new
cr
for
that
and
behind
the
scenes,
we're
using
a
component
called
vmio,
which
that
does
import
a
single
vm.
So
for
each
vm
we
are
creating
one
single
import
and
we
are
orchestrating
all
the
inputs
allowing
us
to
have
throttling
at
the
vm
and
plan
level.
B
I
mentioned
the
validation
service.
Actually,
we
know
that
some
migrations
will
fail.
So
what
we
want
to
do
is
one
don't
block
it's
one
of
our
motto
for
a
long
time
and
we
want
to
to
expose
the
user
the
concerns
we
have
and
we
also
want
to
fail
fast.
We
don't
want
to
discover,
after
the
migration
that
the
vm
is
not
suitable
and
we've
lost
time
by
shutting
down
the
source
vm.
It
discover
that
it's
not
going
to
work.
B
We
have
an
expandable
and
multi-level
rule
set
as
code
and
it
generates
concerns
every
time
it
finds
a
rule
is
matched.
We've
got
a
concern
and
we
expose
a
concern
in
the
plan
creation
wizard
because
we've
got
the
ui
I
mentioned
crs,
but
we've
got
a
ui
and
I'll
show
that
the
plant
condition
reflects
the
validation.
B
So
you
you
know
when
you
plan
that
the
plan
is
suitable
to
be
migrated
or
run
directly,
and
we
also
provide
the
pre-migration
analysis
at
scale.
We're
doing
the
pre
the
analysis
before
you
even
create
a
plan,
so
you
can
have
all
the
information
right
away
for
that.
We
are
using
open
policy
agent
that
is
well
known
in
the
kubernetes
ecosystem
and
if
you
want
more
information
here
is
a
link
I'm
going
quickly
over
a
demo
that
will
show
you
the
user
interface.
B
B
Let's
call
it
demo,
I
select
the
tools
provider
I
just
created
the
destination
host
is
actually
the
the
open
chip
cluster
or
the
kubernetes
cluster,
and
the
operator
is
running
on
so
it's
created
when
you
deploy
things
when
you
deploy
forklift,
you
don't
have
to
do
it
manually,
so
we're
we're
gaining
some
time
there.
Then
I'm
selecting
vms.
So
you
can
see
that
there
is
some
filtering.
B
You
can
also
see
the
warning.
All
the
vms
in
this
cluster
have
at
least
one
warning
is
due
to
drs
being
enabled
on
the
cluster
for
the
list
of
vm.
I
will
create
a
mapping,
so
I
say
that
all
the
networks
that
are
used
by
the
vm
will
go
to
the
pod
network.
Microstar
is
quite
small.
I
don't
have
a
lot
of
networks,
same
rules
for
the
storage,
all
the
data
stores
used
by
the
vms
go
to
standard.
B
B
I
can
go
into
the
kubernetes
or
openshift
console
and
see
the
result
here.
I've
I
have
my
two
vms,
I'm
just
starting
them
from
the
cubejet
interface
and
because
I'm
playful
I'm
going
to
show
you
the
vm
running
windows.
That
would
be
too
easy
to
show
linux
and
from
the
console
directly
I
can
access
the
virtual
machine
console.
So
it's
consolidate
console
kind
of
inception,
but
you
you
see
the
idea.
We've
got
access
directly
to
the
windows
machine
that
has
booted,
so
that
was
it
for
the
forklift
site.
C
C
A
typical
use
case
of
crane
could
be
that
maybe
you
have
an
older
cluster
and
you
have
an
application.
That's
been
running
there
for
a
year
or
two,
and
now
you
have
a
new
cluster,
it's
up,
and
you
want
to
migrate
that
application
to
the
new
cluster.
An
important
thing
is
that
a
lot
of
these
applications
want
to
migrate.
They
may
have
state,
so
you
can't
just
redeploy
the
application.
You
need
to
be
able
to
migrate
it
and
bring
that
state
with
you
and
crane
is
the
tool
that
we
built
about
with
that.
C
When
we
talk
about
a
stateful
application,
there
are
essentially
three
buckets
of
things
that
make
up
that
application.
There
are
kubernetes
resources.
This
could
be
your
deployments
secrets
services.
Things
like
that
there
could
be
potentially
internal
images
that
were
built
for
the
application
that
are
required
to
run
and
then
also
state
and
persistent
volume.
Data
and
crane
will
migrate.
All
those
three
things
to
the
destination
cluster,
so
your
application
will
be
running
and
you'll
have
that
state
in
the
destination
cluster
that
you
originally
had
in
the
source.
C
C
I
have
about
two
three
minutes
I'll
go
over
this
quickly.
I
won't
be
able
to
run
a
migration,
but
I
can
show
you
the
basics
of
how
this
works.
Everything
in
crane
is
like
most
things
in
kubernetes,
it's
driven
from
a
custom
resource
api
everything
you
see
in
the
cui.
We
can
do
from
the
api
directly
with
custom
resources.
C
C
The
heart
of
this
is
creating
a
plan,
and
a
plan
is
where
we
describe
what
we
will
migrate
and
how
we're
going
to
migrate
it
so
we'll
create
a
plan
and
first
thing
is
we
just
give
it
a
name?
Then
we
pick
out
our
source
cluster
and
then
we
pick
out
a
host
cluster,
and
this
is
the
destination
of
where
we're
going
to
migrate.
To
next
up
crane
is
going
to
look
in
the
source
cluster.
It's
going
to
find
the
namespaces
that
exist
and
give
us
a
little
bit
of
information
about
those
namespaces.
C
So
we
can
pick
out
what
it
is
that
we
want
to
migrate.
In
this
case,
I
want
to
migrate
the
parks
app
so
I'll,
select
that
namespace
I
could
select
other
namespaces
as
well.
If
I
wanted
to,
but
we'll
just
do
one
now,
crane
will
take
a
few
seconds
to
look
inside
that
namespace.
It's
looking
at
parks
app
and
it's
find
out
what
are
their
persistent
volumes
that
are
being
used
by
that
application.
C
C
So
next
we
have
a
few
copy
options
that
we
could
change.
We
could
do
a
file
system
copy
or
we
could
do
a
volume
snapshot,
we'll
stay
with
a
file
system
copy,
and
then
we
can
also
pick
out
the
storage
class
in
this
case
we'll
be
going
to
an
ebs
back
storage
class.
So
if
you
notice
here,
we
had
a
source
application,
that's
being
backed
with
gluster
fs
storage
and
we're
going
to
migrate
to
a
destination.
It's
actually
using
ebs,
so
we'll
be
changing
the
storage
type.
C
When
we
do
this
and
then
we
have
some
options
that
just
verifying
that
we
do
have
the
ability
to
do
direct
image
and
pv
migration
they'll
make
this
a
little
bit
quicker,
and
the
last
piece
is
that
we
could
augment
the
migration
and
add
other
steps.
Maybe
if
there's
something
that
before
we
do
the
migration
we
want
to
do
something
off
cluster,
perhaps
change
a
load
balancer
take
an
application
out
of
rotation,
something
like
that.
You
can
add
some
ansible
hooks
that
would
run
with
a
migration
so
that
completes
creating
the
plan.
C
Now
you'll
see
that
we
came
up
with
a
few
warnings,
and
this
is
because
the
we
have
validation
logic
that
will
look
for
anything
that
could
be
abnormal
and
let
you
know
about
this
before
you
go
ahead
and
do
the
plan
in
this
case
it's
telling
us
that
there
was
node
selector,
it's
being
used
in
the
source
side
and
we're
going
to
clear
it.
So
it
doesn't
impact
when
we
do
the
migration.
C
C
A
So
thanks
a
lot,
john
thanks
for
being,
oh
sorry,
for
the
mute.
Of
course,
we
would
like
you
to
join
the
conveyor
community.
Please
go
to
conveyor.io
and
find
more
information
next,
please,
and
you
could
see
in
in
conveyor
of
course,
that
you
could
pros
to
to
the
page
go
to
contacts,
find,
join
the
community,
and
then
you
will
get
invitation
to
to
see
the
meetups,
and
even
if
you,
you
propose
something
you
could
also
join
and
provide
meetups
and
get
early
access
to
the
code
and
access
and
build
up
tools
next,
please!
So!