►
Description
In this video we're going to demonstrate the migration of virtual machines from Red Hat Virtualization to OpenShift Virtualization using the latest Red Hat Migration Toolkit for Virtualization (MTV) solution.
A
Hi,
my
name
is
rhys
oxnam,
I'm
the
director
of
the
customer
and
field
engagement
team
here
at
red
hat
in
this
short
video,
I'm
going
to
be
demonstrating
the
migration
of
virtual
machines
from
red
hat
virtualization
to
openshift
virtualization
via
the
migration
toolkit
for
virtualization
or
mtv
for
short,
a
project
based
on
the
upstream
conveyor
forklift
project,
I'm
going
to
be
covering
both
cold
migration
and
warm
migration,
enabling
customers
to
have
flexibility
with
their
migrations,
whilst
also
ensuring
minimal
downtime.
When
switching
over
for
the
purpose
of
keeping
this
video.
A
As
short
as
possible,
many
sections
have
been
sped
up
in
the
demonstration
environment.
We
have
red
out
virtualization,
where
we
can
see
a
single
rail,
8,
virtual
machine
running
and
also
openshift
virtualization,
where
we
can
see
a
single
rail,
9
virtual
machine
running
we're
going
to
be
migrating.
This
rail
8
virtual
machine
from
rev
over
to
openshift
we've
got
a
basic
workload
running
on
this
virtual
machine
that
simply
displays
a
hello
message
from
an
nginx
server,
with
the
current
server
address
being
shown.
A
A
A
In
this
environment,
I've
only
deployed
the
operator
with
a
very
simple
configuration,
I'm
yet
to
configure
any
of
the
providers
and
therefore
will
have
to
walk
through
all
of
the
providers
and
the
various
mappings
that
enable
the
solution
to
determine
how
to
map
storage
and
networking
interfaces
between
the
platforms
out
of
the
box.
The
operator
will
have
to
find
the
host
provider,
which
is
the
cluster
in
which
mtv
is
already
running.
On
top
of
in
this
demonstration.
This
will
also
be
our
target
cluster,
but
it
can
also
act
as
an
intermediary
between
classes,
if
required.
A
Currently,
mdv
supports
three
different
options:
vmware
red
hat
virtualization
and
openshift
virtualization
itself,
as
this
tool
can
be
used
to
move
virtual
machines
between
openshift
clusters
too,
as
this
demonstration
is
targeted
at
rev,
we'll
select
red
hat
virtualization.
Now
now
we
have
to
provide
some
additional
configuration
information,
so
mtv
can
connect
to
the
rev
api
and
be
able
to
scrape
the
necessary
information
as
well
as
pull
data
out,
we'll
give
it
a
provider.
A
A
For
example,
if
you
had
a
vm
that
utilized
nfs
based
storage
on
rev,
but
you
wanted
it
to
automatically
map
to
using
ceph
on
openshift,
we
can
define
that
mapping
here
by
leveraging
an
available
storage
class
and
the
same
for
networking.
If
we
utilize
the
vlan
tag
network
on
rev,
you
can
map
it
to
the
equivalent
configuration
provided
by
a
network
attachment
definition
in
openshift.
A
We'll
first
define
the
network
mapping
and
we'll
give
it
the
name
of
revm
network,
we'll
then
choose
our
rev-m
pem-lab
source
provider
and
select
the
host
target
provider.
This
will
then
dynamically
populate
the
network
list
for
both
allowing
us
to
choose
the
appropriate
configuration.
We
have
a
very
simple
configuration
in
the
demonstration
environment
where
our
rev-based
vms
utilize,
the
overt
management
network
and
we've
got
an
equivalent
data
center
network.
That's
been
defined
in
openshift
that
will
put
workloads
onto
the
same
layer,
2
network,
so
I'll
make
this
mapping
now.
A
Now
we've
done
the
network
mapping
I'll
move
over
to
storage
and
it's
much
the
same
thing
we'll
give
it
a
name:
we'll
select
the
source
provider
and
the
target
provider
and
we'll
attach
our
simple,
hosted:
storage
from
rev
as
the
source
and
have
that
map
to
the
seth
rpd
storage
class.
On
the
openshift
side,.
A
Now
we've
got
both
storage
and
network
mappings
complete
at
this
stage,
we're
ready
to
start
our
first
migration.
For
this
we
need
to
create
a
migration
plan
that
will
pull
all
of
the
providers
and
mappings
together
into
a
definition
of
what
we
want
to
migrate,
we'll
select
migration
plans
and
then
create
where
it
will
ask
us
a
number
of
questions.
A
A
For
now
on
the
next
page,
I
can
select
my
virtual
machines
that
I
want
to
migrate
and
mtv
will
have
already
scraped
a
list
of
vms
from
the
rev
cluster
and
I'll
select
the
pem
lab
data
center
in
my
web
environment,
and
you
can
see
that
it
has
noted
two
potential
virtual
machines
to
migrate
on
the
next
page.
It
shows
that
there
are
two
virtual
machines
that
could
be
migrated.
The
hosted
engine,
which
is
the
rev
manager
itself,
which
we'll
ignore,
and
the
rail
8vm1
virtual
machine
that
we
do
want
to
migrate.
A
Mtv
runs
a
migration
assessment
which
highlights
potential
issues
that
may
arise
when
migrating
virtual
machines
onto
openshift,
where
it
shows
us
a
warning
for
our
rel
8vm.
If
we
expand
that
it
shows
that
there
are
some
simple
issues
that
won't
block
the
migration,
but
are
perhaps
something
to
be
aware
of.
A
Let's
now
make
sure
this
virtual
machine
is
selected
and
we
can
proceed
further.
We
can
now
select
our
network
and
storage
mappings
that
we
previously
configured,
which
it
will
give
a
visual
indication
of
the
configuration
to
ensure
it's
as
we
expected
to
be,
which,
in
our
case,
everything
looks
good.
A
It
will
then
ask
us
for
a
migration
type
where
we
choose
between
a
cold
migration
or
a
wall.
Migration.
A
cold
migration
is
where
the
source
virtual
machine
is
powered
down
before
the
vm
data
is
migrated
and
then
is
started
on
the
target
platform,
whereas
a
wall
migration
keeps
the
source
vm
running.
Whilst
data
is
copied
in
the
background
enabling
a
quick
cutover
to
minimize
downtime
between
shutting
down
on
the
source
and
booting
on
the
target,
we'll
start
off
with
a
cold
migration,
then
later
we'll
rerun.
The
migration
with
the
warm
options
afterwards,.
A
A
A
A
A
A
A
A
And
we'll
remove
the
migration
plan
on
the
mtv
ui,
meaning
that
we're
basically
back
to
where
we
were
before
we
started
with
the
cold
migration.
Now
I'm
going
to
quickly
run
through
the
creation
of
a
second
migration
plan,
where
it
will
be
almost
identical
to
the
first
one,
but
we'll
use
the
wall.
Migration
type.
A
Like
before
the
migration
plan
is
ready-
and
I
can
start
it
when
I
select
start,
it
will
ask
me
whether
I'm
ready
to
start
the
incremental
copies
behind
the
scenes.
A
snapshot
of
the
virtual
machine
is
being
taken
on
the
website,
allowing
the
snapshot
data
to
be
migrated
without
affecting
the
running
virtual
machine.
A
In
openshift,
we'll
see
a
virtual
machine
in
the
provisioning
state
and
like
before
an
importer
pod
is
running
pulling
the
data
from
the
snapshot.
This
time
all
whilst
the
virtual
machine
on
the
website
is
still
running
uninterrupted,
all
of
this
data
is
being
pushed
into
a
persistent
volume
claim
residing
on
ceph
storage.
As
per
our
mapping
request.
A
After
a
few
minutes,
we'll
see
that
the
migration
plan
status
moves
into
an
idle
state
where
it
will
schedule
a
further
incremental
copy
later
down
the
line
to
allow
us
to
choose
the
cut
over
time,
we'll
force
mdb
to
cut
over
right
away
by
selecting
the
cut
over
button
and
opting
to
start
it
right
away,
rather
than
scheduling
it
for
later.
For
example,
during
a
maintenance
window.