►
From YouTube: KubeVirt - Kubernetes, Virtualization and Your Future Data Center [I] - Itamar Heim & Fabian Deutsch
Description
KubeVirt - Kubernetes, Virtualization and Your Future Data Center [I] - Itamar Heim & Fabian Deutsch, Red Hat
Kubernetes is a great orchestration tool for containers, but why stop there? Containers and virtual machines are going to co-exist in the data center. Let’s re-envision our virtualization and cloud solutions with Kubernetes as a single underlying platform.
We’ll introduce KubeVirt - a project to converge the future data center using Kubernetes as its infrastructure. We will cover how we are implementing a caring and stateful environment to run pet VMs in containers on top of Kubernetes - without contradicting its core assumptions. We will also be discussing gaps and how we plan to tackle those, drawing on our experience with KVM and and caring for pet VMs (and cats) for many years. The session will also include a demo of how we are doing this today and where we want to go next.
About Fabian Deutsch
Associate Manager, Red Hat
About Itamar Heim
Red Hat
Senior Director, Software Engineering
Itamar Heim is a Senior Director of engineering for Container, Virtualization and System Management. Itamar leads the community and product engineering teams comprising Satellite, Red Hat Enterprise Virtualization and Container Management groups. Prior to this Role Itamar worked on architecture and technology as a Consulting Software Engineer in Red Hat, and as Chief Architect in Qumranet. Itamar has over 18 years of experience in managing development and integration of complex enterprise-grade software systems, specializing in management of networking, security and virtualization. Itamar holds an MBA and a bachelor degree in computer science.
Join us for KubeCon + CloudNativeCon in Barcelona May 20 - 23, Shanghai June 24 - 26, and San Diego November 18 - 21! 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.
A
To
talk
about
Qbert
a
project
we
started
to
look
at
what
can
we
do
about
virtual
machines
and
containers,
so
I
actually
come
from
Coomer
net,
the
startup
that
created
KVM
later
acquired
by
Red
Hat,
and
do
a
lot
of
cool
things
about
caving?
What
one
of
the
cool
things
cool
things
about
was
that
it
made
virtual
machines
just
another
user
process
on
Linux
running
just
a
single
virtual
machine.
You
know,
what's
very
cool,
that
we
could
do
it
on
Linux.
A
But
in
order
to
solve
customer
problems,
real
use
cases,
you
need
to
look
at
clustered
environments
right
so
shared
storage,
sure
networking
managing
the
full
lifecycle.
This
is
where
over
at
reddit
virtualization
came
from
for
the
virtual
enterprise
virtualization
use
case,
evolution
later
on
the
cloud
use
case,
OpenStack
solving
that
problem
infrastructure
as
a
service
still
running
mostly
virtual
machines.
A
Also,
now
looking
at
different
workouts
like
containers
trying
to
virtualize,
not
just
the
virtual
machines
but
also
network
storage,
abstraction
other
layers,
more
consuming
through
api's
as
well
and
then
kubernetes
came
along
well,
containers
came
along
and
kubernetes,
and
the
nice
thing
about
kubernetes
is
that
it
tries
to
do
something
similar,
but
for
a
more
generic
use
case
for
us
right,
it's
not
focused
on
virtual
machines
rather
on
any
process,
so
orchestration
of
processes
on
a
shared
cluster
same
problem
right
cluster.
How
do
I
access
storage?
How
do
a
virtualized
network?
A
Now,
if
virtual
machines
are
just
user
processes
and
the
ology
by
the
way,
use
some
of
the
same
isolation
level
technologies
like
SL
innards,
like
C
groups,
so
they
don't
do
namespaces,
but
they
do
use
some
of
the
other.
Similar
isolation,
technologies
and
kubernetes
can
do
this
for
any
user
process.
Can
we
just
handle
both
of
them
on
a
single
environment
with
kubernetes.
A
Now,
why
would
we
want
to
do
this?
So,
yes,
containers
are
the
new
cool
thing
they're,
not
that
new,
but
like
adoption,
let's
call
it.
Ai
is
new
and
everyone
wants
to
do
the
new
things
with
containers,
but
it's
going
to
take
time.
Ok,
not
everything
is
going
to
work
the
ROI
to
convert
to
containers
a
lot
of
enterprises
still
have
mainframes
right
that
have
been
dying
every
decade
fast
too.
So
it's
going
to
take
a
while
foreseeable
future.
We
can
expect
virtual
machines
are
going
to
stay
on
premise.
A
A
Would
you
want
to
run
multiple
environments
side-by-side
different
technologies,
or
would
there
be
benefit
to
converge
to
a
single
infrastructure
that
can
run
the
different
workloads
using
similar
tools,
similar
processes
benefitting
you
know
from
that
efficiency
leading
to
cost
reduction?
In
the
end?
A
It's
also
nice,
as
you
will
be
migrating
workloads
from
virtual
machine,
so
new
workloads,
let's
say
you're-
writing
them
with
containers
existing
workload,
you're
hoping
you're
going
to
be
able
to
move
them
to
containers
as
you
do
that
it's
easier,
it's
going
to
be
easier
if
it's
going
to
run
on
the
same
infrastructure.
So
if
I
have
a
bunch
of
virtual
machines
running
in
a
cluster
of
hosts
and
I
convert
the
application,
maybe
I
don't
start
with
a
database,
but
would
you
know
with
the
front
end
and
the
back
end
logic?
A
If
I
can
keep
the
affinity
running
on
the
same
infrastructure
on
the
same
host
on
the
same
cluster
and
not
an
entirely
different
infrastructure,
it's
going
to
be
more
efficient,
I!
Don't
need
to
think
about
when
do
I
move.
You
know
the
server's
from
this
side
to
that
side,
I
don't
need
to
over
provision.
My
servers
and
I
can
get
benefit
from
similar
same
network,
same
affinity,
same
storage,
things
like
that.
A
Another
nice
things
that
some
of
the
kubernetes
concept
some
of
them
exist.
You
know
scheduling
is
pretty
advanced
and
virtualization
and
OpenStack
world,
but
some
of
the
concepts,
if
we
can
just
make
the
virtual
machine
just
another
pod-
are
very
nice,
so
o
demon
said
there
are
a
lot
of
use
cases.
We
do
that
for
virtualization
today,
kubernetes
again
is
very
nice,
and
it
simplifies
this
for
the
generic
use
case
and
virtual
machines
become
relevant.
The
benefits
to
kubernetes
is
there's
a
lot
of
experience
in
the
virtualization
space.
A
A
Now
there
are
different
use
cases
for
running
virtual
machines
on
kubernetes.
One
of
them
is
I,
want
better
isolation.
I
want
to
run
a
container,
but
I
want
to
run
it
in
a
virtual
machine
for
better
isolation.
I
believe
that
a
virtual
machine
it
has
smaller
surface
of
attack.
Things
like
that
I
know
how
to
run
to
protect
the
ends.
I
want
to
run
my
container
work
in
a
vm.
I
want
to
run
CI
a
firm,
o
vm
things
like
that.
That's
not
the
use
case,
we're
focusing
on
that's
the
container
use
case.
A
You
know
with
the
nuance
on
the
technology
being
run.
That's
not
why
we're
not
focusing
on
that.
It's
an
interesting
use
case.
It's
not
going
to
lead
to
convergence.
You
won't
see
enterprise
virtualization
customer
vmware
customer
going
to
that
use
case.
So
we're
focusing
on
for
the
convergence
is.
Can
we
solve
the
full-fledged
vm
use
case
now
in
virtualization?
You
know
a
bit
more
maturing
space
in
management
system,
lifecycle,
etc.
Kubernetes
again
very
promising.
A
Moving
really
fast
still
has
some
gaps
compared
to
the
years
of
things
being
done,
virtualization
similar
concept,
you
know
managing
clusters,
storage
networks,
things
like
that
and
a
slew
of
features
that
exist
in
virtualization,
not
going
to
go
for
all
them
or
the
gaps
just
example,
and
as
we
enumerate
them,
we
see
that
some
of
them
are
very
generic
and
relevant
to
kubernetes
and
to
containers,
and
some
of
them
are
specific
to
virtualization,
but
hey,
not
so
bad.
We
can
make
them
fit
easily,
so
things
like
shared
memory.
A
So
if
I
run
multiple
virtual
machines,
similar
workload,
similar
operating
system
I
can
use
what's
called
KSM
sibling
of
KVM
looking
at.
How
can
I
do
shared
memory
for
my
virtual
machines
that
is
relevant
for
containers
running
similar
workloads
on
the
same
host?
I
can
converge
those
memory
pages
memory,
ballooning
more
specific
to
virtual
machines,
less
relevant
for
containers,
we're
looking
at
scheduler,
so
kubernetes
is
a
pluggable
pluggable
scheduler
and
in
virtualization
space.
A
Similar
concepts
do
I
want
to
schedule
for
performance
across
my
hosts
slow
down
as
much
as
possible,
or
maybe
I
want
to
converge
and
save
on
power
to
power,
saving
policies
so
converge
as
much
as
possible
overnight,
and
you
know
then
again
spin
out
in
the
morning.
So
I
can
shut
down
some
of
my
servers.
A
So
kubernetes
has
pluggable
schedule.
It
doesn't
have
the
already
existing,
let's
say,
80
different
scheduling,
policies
that
exist
in
OpenStack,
so
there
are
gaps
to
close
in
that
area.
Another
aspect
is
HR
reservations,
so
a
lot
of
the
focus
in
virtualization
is
around.
How
do
I
handle
failures?
Okay?
Why?
Because
I
didn't
write
my
code
in
2017
to
scale
out
and
handle
you
know:
replication
controller
spanning
for
availability,
but
it's
running
on
a
single
machine
and
if
that
fails
or
the
host
it
runs
on,
fails,
I
want
to
make
sure
I
can
run
it
again.
A
My
shared
storage
would
be
my
file
system
or
my
database
for
containers
if
I'm
running
at
Postgres
container
and
process
Bob
if
the
nodes
failed,
if
I
don't
run
it
again
without
making
sure
that
node
is
down
I'm
going
to
cross
my
database
so
similar
concept.
But
you
know
what,
when
we
look
at
this
at
gaps,
though
okay
I
don't
see,
the
node
can
I
make
sure
it's
down
fencing.
It
is
going
to
kill
all
the
workloads
on
it.
A
So,
let's
make
sure,
maybe
not
just
rely
on
the
network
tap
that
node
is
using
shared
storage.
It
keeps
some
lease
on
that
storage
may
be
used
to
check
it
with
another
node.
If
that
storage,
lease
is
still
active
before
fencing
it,
so
maybe
just
my
networking
is
down.
Is
it
me
or
you
know,
is
it
you
or
is
it
me?
Okay,
if
I
don't
see,
one
note,
I
should
sense
it
by
don't
see
50
percent
of
the
node.
A
Maybe
it's
me
I
shouldn't,
you
know,
kill
the
rest
of
the
cost
going
to
defining
those
power
management.
Sensing
devices
again
there
are
a
lot
lots
of
lots
of
requirement
and
experience
there.
Okay
first
thing
you
want
to
do
is
try
the
fencing
device
on
the
physical
host,
IPMI,
ILO,
etc,
going
to
create
a
nice
shutdown
process.
So
that's
your
first
priority
device,
but
you
define
multiple.
If
that
didn't
work,
maybe
try
with
SSH,
then
with
ipmi
that
didn't
work,
you
can
actually
go
and
turn
off
the
power.
A
Okay
to
that
server,
it
probably
has
two
sockets,
so
you
need
to
do
you
know.
First,
priority
is
ipmi.
If
not,
then
the
second
priority
is
to
different
tensing
devices
together
and
before
you
fence
the
device,
maybe
it's
dumping,
and
if
it's
you
know,
a
host
with
a
terabyte
or
two
terabyte
of
RAM
could
take
a
while
for
the
dump
to
happen,
and
if
you
care
about
this
done,
then
you
want
to
not
sense
the
host
until
it
finished
a
dumping.
A
So
you
want
to
check
something
before
you
do
anything
so
again,
a
lot
of
things
not
directly
related
to.
How
do
I
schedule
my
or
clothes?
Rather,
how
do
I
handle
Baylor's?
How
do
I
handle
host
life
cycle
network
configuration
so
very
cool?
You
know
virtual
networking,
VX
LAN,
all
those
in
the
cloud
and
kubernetes
space,
but
when
you
look
at
virtual
machines
and
again
we
look
at
those
because
we
care
about.
A
If
we
want
to
make
this
converge,
we
need
to
preserve
the
behavior
lower
the
barrier
of
entry
for
anyone
running
virtual
machine
and
expecting
this
to
behave.
They
need
to
change
to
the
new
world.
Okay,
it's
a
huge
change
in
training
behavior
in
what
they
need
to
do.
If
we
can
make
it
as
similar
as
possible
to
move
to
a
newer
technology
but
preserve
concepts,
then
you
know
easier
barrier
to
move,
and
in
this
case,
if
they're
virtual
machines
are
running
using
layer,
2
VLANs
and
they
really
care
about
again
robustness.
So
they
care
about.
A
How
did
you
ebon
the
physical
interfaces
on
the
host
again
not
related
to
hi
device
orchestrating
my
workload,
but
how
do
I
make
sure
my
environment
is
ready
and
then
we
get
to
the
beam
definition,
lots
of
parameters
there,
some
of
them
relevant,
some
of
them
out
the
remote
my
audio/video
not
relevant,
hopefully
live
migration
is
going
to
be
relevant
for
containers,
there's
like
policies
and
nuances
around
by
migration.
How
do
you
CPU
pinning
Numa
pinning
thing
like
things
like
that?
A
So
a
lot
of
different
gaps
in
you
know
that
between
comparing
what
we
have,
which
is
obviously
you
know
a
lot
of
years
and
really
mature-
do
a
very
promising
technology
with
a
lot
of
cool
things
in
it.
Some
of
those
gaps
nicely
generic,
some
of
them
more
specific
to
virtualization.
Now,
can
we
close
them.
B
Thanks,
so
it
is
not
talked
a
lot
about
why
we
want
to
do
that
and
how
VM
look
and
what
we
need
to
express
if
we
want
to
run
them
on
kubernetes.
So
and
that's
what
we
did,
we
looked
when
we
started
to
look
into
this.
We
started
with
a
research,
so
we
looked
what
what
did
exist
at
that
time,
so
I
mean
starting
at
the
bottom
of
the
slides.
So
we
looked
at
Birdland,
hyper
and
clear
containers
were
not
there
yet,
but
we
were
keeping
them
inside
over
time
by
looking
what
we
required.
B
So
so
we're
learning
about
communities,
and
then
we
start
to
say:
okay,
how?
How
do
we
express
what
we
need?
How
do
we
express
that
in
communities
and
the
question
was:
can
we
express
that
in
a
pot
pacification,
for
example,
in
the
API
of
a
pot,
or
do
we
require
a
specific
entity
to
express
all
the
details
we
require
for
our
fully
fledged
areas?
B
That
was
actually
a
question
which
is
also
differentiating
the
existing
approaches
which
are
somehow
related
to
the
end,
so
the
Berlet
or
or
hyper
or
clear
containers,
because
some
of
them
are
using
the
MS
transparently
to
the
user.
So
you
can't
really
address
specific
details
of
the
VMS
and
in
other
approaches
like
in
the
worklet
work
that
you
have
to
some
degree
to
control
over
how
the
real
running
vm
is
looking.
B
So
that
is
what
we
were
looking
at
and
then
we
were
looking
okay,
but
if
we
now
get
to
running
VB
and
how
should
that
be
looking,
there
are
several
ways
of
how
to
do
it.
So
the
CR
I
was
just
emerging
at
that
point
in
time
like
half
year
or
a
year
back.
So
we
look
to
us
know
what
was
actually
before
the
TR
item.
So
we
look,
it
doesn't
make
sense
to
implement
a
different
runtime
inside
the
cubelet
to
run
VMs,
and
can
we
somehow
pass
all
the
necessary
parameters
to
that
runtime?
B
Does
that
work?
But
we
also
looked
at
another
approach
where
we
basically
said
we
don't
want
to
run
the
VM
by
the
by
the
cubelet,
because
the
cubelet
doesn't
provide
us
all
the
necessary
functionality.
For
example,
when
it
comes
to
Numa,
pinning
or
guarantees
about
I,
don't
know
accessing
a
host
agent
inside
the
VM.
B
In
the
end,
we
saw
that
the
existing
approaches
focused
and
the
later
review
is
that
the
vert
led
folks,
but
on
the
port
API
and
how
to
run
VM
sphere
hyper,
also
used
VMs
for
transfer
and
isolation
and
like
clear
containers.
So
we
didn't
have
direct
access
to
DVS
and
because
those
approaches
were
using
or
looking
into
the
transparent
approach
or
more
transparent,
we
looked
okay.
Let
us
try
to
create
a
specific
API
for
a
VM
to
express
all
our
needs
as
Itamar
set.
B
B
So
to
start
with
the
API
I
said
we
created
our
own
API
and
what
we
can
T
God
is
similar.
Looking
to
what
you
see
on
the
slide,
so
you
get
all
the
it's
looking.
It's
a
regular
kubernetes
object,
so
it's
implemented
using
GPRS
and
the
header
is
looking
like
like
a
quat
specification,
but
then
you
get
into
the
details
in
the
domain.
They
got
all
the
glory
and
small
details.
B
You
need
for
VM
I
just
have
here
a
small
small
part
of
what
you
can
express,
but
you
can
easily
extend
with
adding
controllers
for
specific
PCI
devices.
Usb
devices
additional
displays,
I,
don't
know
pass-through
of
USB
devices
on
a
chroma
client.
All
of
that
needs
to
be
expressed
in
a
specification
if
we
want
to
do
if
we
want
to
run
the
M
in
then
tightly
so
so
completely
in
an
enterprise
environment
but
yeah.
So
that
is
our
API,
but
this
API
is
just
an
abstraction
because
some
of
the
part
can
already
handled
by
kubernetes.
B
For
example,
if
we
look
at
the
top,
we
see
there
that
this
specification
contains
a
lot
selectors
so
that
you
can
select
where
you
want
to
run
the
VM
in
that
case,
but
kubernetes,
so,
oh
yeah,
so
kubernetes
provide
the
same
functionality
for
pods.
So
for
us
it
was
easy.
We
were
running
VMs
in
import,
that
we
could
reuse
that
functionality
from
kubernetes,
and
that
was
actually
a
name
of
us
to
be
able
to
leverage
internality,
which
is
already
present
infinitives
starting
work.
With
that
note
selector,
then.
B
B
Currently,
we
were
also
looking
at
how
we
can
attach
other
objects
to
vm,
so
how
we
can
reel
other
resources
inside
the
cluster
and
we
started
with
using
volumes
because
they
are
there
today
and
volumes
also
something
you
often
require
with
the
ends,
because
they
need
to
dip
to
run
on.
And
so
here
we
try
to
convey
to
make
to
enable
us
to
consume
existing
volumes
which
are
available
in
the
cluster
and
share
them
actually
without
the
pot,
if
necessary,
not
not
at
the
same
time,
but
as
needed.
B
So
I
already
said
that
some
of
the
parts
are
being
mapped
to
communities
to
allow
the
scheduler,
for
example,
to
have
an
inside
of
what
the
resource
requirements
of
the
web
will
be,
and
we
do
that
by
writing
them
into
the
pot
specification
and
to
give
you
some
background,
because
we
didn't
get
to
that.
Yet
our
VM
will
be
running
in
these
in
this
space
of
a
pot
I
give
space
because
it's
untainted
and
so
for
every
VM
we
are
running.
B
B
But
in
the
end
and
that
to
highlight
that
we're
doing
research
that
specification,
you
saw
it's
just
one
approach.
There
are
also
other
approaches
which
we
are
looking
into,
which
might
make
more
sense,
because
that
reproach
which
I
showed
is
specific
to
having
really
pet
VMs
or
up
to
full
control.
You
have
the
full
control
over
how
each
and
every
VM
is
looking,
but
if
we
think
about
templating
VMs,
like
it's
more
common
in
the
in
the
cloudiest
case,
then
that
patent
did
not
work
out
so
well.
B
So
a
pattern
which
would
work
better
is,
for
example,
if
we
say
we
associated
a
VM
template
or
VM
config
to
a
pod.
So
whenever
because
then
we
cannot
only
associate
that
template
to
a
pod,
but
also
to
other
objects
like
deployment
or
replication
controllers
and
daemon
says,
because
in
that
case
we
could
use
those
constructs.
Those
concepts
to
to
get
VM
spawned,
like
those
concepts,
would
be
used
inside
of
communities.
B
For
example,
if
we
take
a
replication
controller,
which
we
count
of
five
and
it
references
VMs,
then
we
would
expect
that
the
replication
controller
or
an
associated
component
is
forming
those
five
instances
of
VMs
and
in
the
end,
yet
another
way
of
how
to
express
them.
How
VM
could
be
running
is
even
a
more
simplistic
approach
which
we
thought
is
much
closer
to
what
communities.
B
What
would
expect
how
how
running
VMs
would
look
like,
and
that
shown
on
the
right
side
of
the
slide,
that's
really
minimalistic
approach,
but
which
would
be
more
suited
for
kubernetes
eventually,
because
it's
it's
clean,
its
dense
and
you
have
sane
default,
but
it
did
not
meet
our
requirements
of
having
the
full
control
over
over
DVM
itself.
So
we're
still
looking
what
is
the
right
approach
to
cover
our
pet
DM
use
case
in
the
cloud
VM
use
case,
but
also
to
be
friendly
for
communities,
because
that
is
what
we
are
also
looking
for.
B
So
what
I'm
going
to
show
you
is
now
to
how
that
basically
works,
we're
already
good
on
time,
so
I'll
make
it
ends
on
the
right
hand,
side
you
see
that
there
are
a
few
things
running
on
the
clock
that
we
will
get
to
them
in
a
moment,
but
to
show
the
really
important
bit
is
that
can
really
work
with
the
ends.
So
what
I've
prepared
is
a
small
cube,
CTL
wrapper
because
and
that's
where
we
also
see
a
bunch
of
issues
where
ladies
is
for
for
the
MC
needs.
B
B
At
the
EM
specification-
and
he
says
the
MTS
iam
was
created-
that's
really
helpful.
So,
on
the
right
hand
side
you
now
see
that
we
created
that
pod,
where
the
game
is
going
to
be
launched,
that
it
was
scheduled
and
is
running,
but
we
don't
really
see
that
it's
happening,
so
what
we
can
do
now,
and
that
is
why
we
need
the
wrapper
is
you
can
use
some
spice,
which
is
some
kind
of
an
enhanced
VNC
to
actually
exit
the
test
VM
to
see
that
something
is
running.
B
So
this
really
is
a
VM
on
the
host.
We
now
wonder:
ok,
how
do
we
see
where
is
it
running
and
be
good
as
we
can
use
the
native
kubernetes
tool
to
inspect
web,
so
we
can
say,
cube
CTL
cluster
geared
Oh
Jason,
the
Ames
test
VM,
and
we
see
down
here
that
it's
running
on
node
0
I've
done
a
vagrant
set
up
on
my
my
laptop
to
illustrate
that
and
if
we
go
to
the
node
0,
which
you
can
see
up
here,
then
you
see
that
the
test
film
is
really
running
here.
B
B
So
we
know
now
that
the
VM
is
running
on
node
0
and
we
see
that
we
can
introspect
that
with
some
with
cube
CTL,
but
also
because
and
I
will
come
to
the
interesting
part,
so
VMs
have
that
contents
of
people,
our
pet
VMs,
are
not
like
the
transient
VMs,
which
Iijima
mentioned,
but
our
VMs
are
important
and
we
want
them
to
run,
but
it
happens
now,
then,
that
you
need
to
replace
how
it
one
a
host.
So
the
really
interesting
bit
when
it
comes
to
comparing
containers
to
pot
is
I
need
to
migrate.
B
My
VM
way
to
to
do
hardware,
maintenance
or
whatever
or
scale
up
or
repair
something
and
that's
possible
now
so
because
we
said
at
the
end
is
not
a
part,
but
a
VM
is
running
inside
a
pod.
The
nice
thing
we
can
do
is
we
can
just
say:
ok,
let's
take
that
VM
and
move
it
to
another
space.
So
it's
like
a
harbor
for
ships.
B
I
mean
we
are
on
all
that
that
maritime
environment
here
in
kubernetes,
so
we
we
have
that
pot
now
current
hava,
but
we
can
now
say:
let's
move
it
to
another
one,
and
we
can
use
cube
CTL
des
to
actually
get
a
moved
to
to
another
plate,
and
we've
got
here
another
manifest,
which
is
called
money.
Yeah
migration
manifest
the
event
VM
keeps
running,
and
if
we
look
now
at
the
running
pod,
we
see
that
down
here
we've
got
a
migration
per
pod,
it's
still
there
good,
which
is
actually
performing
the
migration.
B
We
also
see
here.
This
is
the
original
hardware
of
the
VMware
20
running
and
the
migration
job
created
a
second
pod
on
another
node.
We
will
see
eventually,
word
lands
and
this
migrations
job
is
also
responsible
for
performing
the
migration,
hopefully,
as
it
is
what
demos
I
expect
this
to
end
successfully,
but
we
need
to
be
a
little
more
patient
and
take
about
a
minute
to
to
complete
in
the
meantime.
B
In
the
meantime,
we
can
take
a
look
at
how
does
this
migration
job
look
at
all,
because
it's
great
just
like
anything
else
here
is
very
simplistic.
It's
just
the
beginning.
There
are
many
more
to
Nobles
to
migrations
like
bandwidth,
throttling
and
making
selections
of
the
destination
host,
and
we
imagine
that
this
is
going
to
be
expected
inside
this
migration
object
which
we
are
creating
on
the
cluster.
In
the
meantime,
thank
you
demo,
the
migration
finished.
B
We
see
that
the
new
product
really
be
was
created
that
we
all
want
old
one
got
cleaned
up
and
that
the
migration
job
has
gone.
We
can
now
verify
that
by
looking
at
the
at
the
location
of
the
of
the
VM,
which
should
now
recite
on
a
on
a
different
note-
and
that's
true
so
previously
was
running
on
lonely
row
now
running
on
master
and
to
show
you
it's
still
boot
or
it
has
booted
and
the
display
still
there
and
that's
really
the
same
VM.
B
If
we
now
look
at
the
master,
we
see
that
the
test
frame
is
here
and
not
anymore,
on
non
zero
and
that's
really
nice.
So
that's
really
nice!
Why?
Because
we
didn't
have
to
contradict
with
any
kubernetes
patterns,
but
we
could
lay
our
virtualization
specific
logic
on
top
and
you
are
not
conflicting
with
kubernetes.
So
I
need
to
come
to
an
end
here
because
we
tight
on
time
but
because.
B
B
B
So
so
because
the
ends
are
yet
just
another
process,
we
obviously
don't
have.
We
don't
have
a
problem
to
run
or
type
of
PMS.
So
you
can
hear
we
can
say
that
if
we
created
second
VM,
that
it
doesn't
matter
if
we're
booting,
Fedora
or
if
it's
another
operating
system
on
this
laptop,
just
an
issue
that
it's
taking
so
much
resources
as
we're
now
running
three
VMs
and
that
one
is
also
running
a
nested
mode.
But
let's
see
if
it's
coming
up
or
not,
oh
there
we
go.
B
So
we
keep
in
spawn
windows
which
is
really
nice
and
kubernetes
because
yeah,
it's
just
yet
another.
We
end
and
we
have
all
the
freedom
to
do
the
tuning
on
the
low-level
to
enable
Windows
launch.
So
these
all
those
ACPI
to
nobles
and
hbt
I,
don't
know
what
wealth
and
by
having
Q
word
being
a
layer
and
not
inside
communities.
We
have
the
freedom
to
do
all
this
cheering.
So
let
me
get
back
to
the
slides
I.
B
C
B
Basically,
we
played
it
implemented
the
operator
pattern
or
one
instance
of
the
operator
pattern,
so
we've
got
a
diamond
set,
which
is
divine
with
vert
ended,
which
is
doing
all
the
heavy
lifting
on
the
notes,
and
we've
got
a
vertical
roller
which
is
taking
care
of
the
cost
one
logic.
So
in
that
case,
whenever
you
created
the
app,
the
vert
controller
is
taking
care
to
create
an
associated
pot
as
I
described.
Whenever
that
pot
is
getting
scheduled,
then
the
vert
end
is
taking
over.
B
They
have
a
lifting
to
launch
the
VM
inside
that
spaces
the
pot
and
that
obviously
doesn't
just
work
for
one
VM
per
host,
but
also
to
multiple.
So
that
was
really
quick
great.
However,
they
are
still
gaps.
We
don't
speak
just
about
launching
the
ends,
but
we
speak
about
the
whole
management
of
games
and,
as
a
team
are
said,
it's
just
not
just
not
VMs
itself.
It's
also
about
the
scheduling
it
was
about
the
ending
error
cases,
and
this
slide
just
illustrates
one
of
the
main
gaps
we
identified
so
far.
B
Some
of
them
can
be
full
in
a
layered
approach
and
so
are
specific
to
virtualization,
but
some
of
those
issues
are
generic,
so
we
aim
with
Qbert
at
and
working
with
kubernetes
to
improve
them
in
that,
cumulatively,
because
we
think
they
are
beneficial
to
two
containers
as
well.
For
example,
let's
take
storage,
we
see
that
authentication
with
ICS
is
currently
not
supported.
Well,
there's
now
OTR
to
support
it
and
that
exactly
the
kind
of
stuff
we
know.
B
B
We
can
do
monitoring
it
abstracts
away
all
of
the
little
details,
which
is
pretty
nice,
but
it
raises
some
summation
like
liberties,
yet
just
yet
another
demon
on
the
host
and
the
cubit
actually
expects
to
be
the
owner
of
all
processes
on
that
or
of
all
the
important
processes
on
the
host,
and
that's
also
necessary
to
make
scheduling
decisions
because
kubernetes
needs
to
be
aware
of
the
resource,
consumption
and
so
on.
Support
cube
is
not
major
enough
yet
so,
for
example,
multipath.
B
If
it
comes
to
connecting
we
on
fibre
channel
so
multipath
setups
that
currently
not
handled
by
kubernetes.
So
we
want
to
understand:
is
it
part
of
kubernetes
what
should
be
handled
by
kubernetes
or
is
it
expected
to
be
just
working?
And
there
are
examples
on
previous
slide
in
all
the
areas
as
well?
The
operator
pattern
worked
out
really.
Well,
well
so,
layering
all
our
logic
on
top
of
kubernetes,
instead
of
pushing
it
into
communities
itself.
B
Let
me
see
what
can
I
go
in
here
yeah,
so
one
obvious
problem
is
that
with
our
approach
of
having
the
runtime
in
situ
containers
so
contained
is
that
we
don't
gain
real
deep
integration
or
cooperation
with
the
cuted
it
has
there
are.
There
are
several
reasons
for
that.
So
first
we
bypass
the
cubelet
for
for
stuff
for
postponing
a
process,
and
so
we
can't
use
features
of
the
cubelet
for
spawning
a
process
or
DVM
process.
So
we
need
to
reemployment
stuff,
but
we
actually
don't
want
to
reemployment
stuff.
B
We
actually
want
to
be
a
friendly
citizen
and
cooperate
with
people
to
then
do
that
stuff
and
we're
still
thinking
about
and
talking
to
deliver
people
and
other
people
can
cube
to
see.
How
can
the
cooperation
between
cubelet
and
River
be
improved
to
to
avoid
that?
We
need
to
replicate
code
on
both
sides
and
how
to
but
it's
difficult,
because
you
have
to
demons,
having
process,
trees
and
and
getting
them
together
and
sharing
functionality
is,
is
a
challenge.
C
B
A
Fabia,
that's
my
slide,
so
just
to
summarize
we're
trying
to
balance
a
lot
of
things
here.
A
bottom-up
approach
is
how
do
we
make
this
play
as
nice
as
possible
with
kubernetes?
So,
if
you
know,
kubernetes
is
the
foundation
and
we
need
to
grow
it
with
features.
How
do
we
make
it
play
as
nice
as
possible
with
kubernetes?
On
the
other
hand,
our
top-down
approaches?
Okay,
we
have
the
virtualization
use
case,
the
cloud
use
case
and
we
know
what
the
gaps
we
want
to
solve
are.
A
How
does
it
look
if
we
go
from
that
approach
to
solve
our
problem
and
keeping
in
mind
that
we
want
to
make
it
now
philosophically
kubernetes
technology
kubernetes
like,
but
from
the
end
user
perspective,
virtualization
like
again
to
breach
the
gap
and
make
it
easier
to
converge
different
use
cases
for
virtualization
we're
just
to
be
clear
again,
we
want
to
focus
not
only
I
want
to
better
isolate
containers,
we're
looking
at
a
full
fledge,
the
end
still
early
potential
very
promising
on.
What
can
we
do,
but
you
know
doing
the
POC
is
that's
very
cool.
A
You
know
running
VMs
in
pause,
live
migration,
which
is
one
of
the
more
advanced
features
of
virtualization.
Really,
nice
fits
very
well.
That's
the
easy
part
doing
you
know
enterprise
virtualization,
doing
robust
application.
80%
of
what
you
spend
your
timing
on
Stefan
is
on
the
airflows.
That's
going
to
be,
you
know,
they're
hard
GAAP.
To
do
this.
It
looks
so
far
like
a
win-win.
You
know
things
that
we
want
to
do
in.
Kubernetes
are
on
the
kubernetes
roadmap.
A
Things
in
kubernetes
lend
themselves
when
I
sleek,
you
advanced
feature
in
virtualization,
so
so
far
looks
really
nice
and
you
know
if
hopefully,
there's
enough
interest
across
different
groups,
so
things
for
something
like
a
special
interest
group
istic
dirt
or
something
like
that
in
the
kubernetes
space
and
obviously
would
love
if
you
can
used
like
to
join
us
on
the
cube
roots.
You
know,
github,
try
the
demos,
look
at
the
code
and
join
the
discussions
on
what
we're
doing
what
soon.
C
A
Yes,
so
the
question
was:
how
do
we
would
like
to
handle
storage
volumes?
Vo
actual
machines
expect
block
storage,
so
one
of
the
things
we're
looking
at
is
not
having
to
cubelet
mount
the
storage
rather
pass
it
through
to
the
pod,
for
example.
So
we
can
do
the
connection
directly
from
the
qmu
process
if
you
think
about
Lib,
gf
api
or
leave
RVD
for
blusterous,
F
or
Isaac
as
a
user
space
office,
cuz
II
can
be
done
from
the
qme
process
themselves.
B
Just
a
small
addition,
a
Tamar's
right,
obviously,
but
we've
got
a
short-term
and
long-term,
so
one
you
can
delegate
it
to
qumu
if
you've
got
if
you've
got
storage
supported
by
Kumho,
like
I,
said
your
RVD,
we
pass
it
through,
but
the
other
idea
is
to
work
with
kubernetes
to
allow
the
delegation
of
the
volume
mounting
and
handling
to
the
container
so
that,
for
example,
you
associate
the
volume
to
the
pod,
but
you
leave
you
to
the
pod
itself
to
do
the
mounting.
What
what
benefit
do
we
have?
B
B
Yes,
the
question
was:
what
about
networking
so
first
networking
turned
about
to
be
a
bit
more
complicated
than
we
expected,
but
that's
not
an
issue.
I
just
spoke
to
the
key
Container
guys
and
they've
got
some
nice
ideas.
So
first
we've
got
the
multi
network
proposal,
which
is
going
much
into
the
direction
of
what
we
need.
So
we
will
be
able
to
attach
multiple
networks
to
pods
and
that
Maps
nicely
to
two
VMs,
because
we
could
say
you
could
at
least
have
one
NIC
per
network.
B
If
we
make
the
assumption
that
you
say
every
network
is
a
NIC
and
then
we
could
play
nice
with
the
kubernetes
concerts
again,
but,
and
that
is
what
we
also
need.
That
is
what
I
would
like
to
see.
A
cig
vert
is
that,
for
example,
layer
two
connectivity
for
VMs
would
be
important
because
sometimes
you
as
a
pet
VM,
you
want
to
have
the
control
over
the
IP
addresses
you
you
give
to
your
VMs.
So
Modi
networks
is
one
topic
later
coding.