►
Description
KVM is a hypervisor offering strong hardware isolation of a guest from it's hosts.
Containers are now a new software based isolation mechanism for workloads, and it might be a small surprise to see that KVM is surfacing in this context quite often.
In this talk we'll look at how KVM is used on the containers and Kubernetes context.
Specifically we'll be looking at the projects KubeVirt, Katacontainers, gVisor, and virtlet, to understand how KVM is used by them to support certain use-cases.
---
Fabian Deutsch
Red Hat
Manager
Fabian Deutsch is working at Red Hat and used to be much more active in the Fedora community as he is today, worked on the oVirt project for a few years, and is now involved in KubeVirt. In the past he had the opportunity to speak at several conferences (KubeCon, oVirt workshops, FrOsCon, LinuxCon, and devconf.cz).
A
So,
if
you
don't
mind,
I
would
start
talking
if
you've
got
a
question
feel
free
to
find
it
good.
It's
a
lot
to
ask
it.
Please
interrupt
me
during
the
talk
that
should
not
be
much
of
an
issue
after
all,
I'm
here
to
answer
your
questions
and
give
you
an
insight
into
the
KVM
use
cases
in
a
container
world.
I
am
myself
I'm
far
beyond
Deutsch
I'm
working
at
red
head
on
virtualization
for
the
last
six
years,
I
started
with
over,
but
that's
pretty
cross.
A
The
stack
so
worked
on
fedora
on
packaging
on
the
low-level
tunings,
pretty
interesting
work,
I,
really
liked
what
I
do
and
I
still
like
what
I'm
doing
today.
So
what
am
I
doing
today
are
working
on
the
context
of
a
virtualization,
the
in
the
container
context,
so
with
containers
and
how
do
they
fit
together?
But
before
we
get
to
that
meat
or
the
vegetarian
option
might
be
an
almost
human
KVM.
A
A
Tested
I
mean
they
are
appearing
in
a
range
of
products
of
companies,
so
OpenStack
is
using
Liberty
Merck
a
VM
we've
got
over
from
red
head,
but
although
others
they
are
used
in
the
cloud
to
support
all
those
cloud
workloads
so
they're,
really
they
they
did
their
mileage.
They
provide
machine,
devil,
abstraction,
a
strong
isolation.
A
All
of
you
could
probably
find
more
attributes
describing
what
queue
medium
can
deliver
to
you
so,
but
then
I
mean
they
empowered
all
of
our
workloads
for
so
long
and
then
containers
came
along
like
three
or
four
years
ago,
and
they
and
today
you
know
everything
is
containers.
If
you
go
to
Q
Khan,
which
exploded
from
I,
don't
know
1,500
people
two
years
ago
to
7,000
people
this
year,
I
guess
cube
con.
Then
it's
pretty
much
like
what
we
see.
A
We
Vulcans
always
saw
with
OpenStack
right
and
the
question
is
what
about
virtualization
and
we
move
KVM
forum
here,
which
is
a
nice
venue.
It's
a
nice
place
great
to
be
in
Edinburgh,
but
where
do
we
seek
a
VM
I
mean
kayvyun
really
showed
it
proved
that
it's
useful.
We
all
know
what
we,
what
values
we
have
from
Q
and
KVM.
Does
it
have
any
place
in
the
container
world,
or
can
we
just
get
rid
of
it?
I
mean
it's
easy
to
duplicate
code.
A
We
need
to
do
some
discussions
of
how
to
duplicate
stuff,
but
in
the
end
we
could
say
right.
Containers
are:
are
there
to
stay?
We
can
address
all
of
the
our
use
cases
with
containers.
So
let's
get
rid
of
kV
mqn
zones
for
right
and
to
answer
that
we
need
to
see
at
what
do
containers
actually
give
to
us.
Why
are
they
so
successful
and
what
what
makes
them
different
to
VMs
so
I
think
one
of
the
things
which
makes
containers
so
attractive
is
that
they
focus
on
the
applications
and
and
the
user
workflows.
A
A
Then
you
know
you
launch
queueing
were
in
another
queue
instance
and
your
two
VMs
on
that
same
note,
a
co-located
with
different
services
that
what
so
so
nice,
but
in
the
end,
you
have
to
have
the
knowledge
of
how
to
set
up
the
operating
system,
how
to
automate
all
that
stuff.
So
it's
a
developer
who
wanted
to
use
a
virtual
machine
and
to
develop
this
in
the
end,
the
guy
who's
developing
the
application
for
for
for
some
use
case
right.
He
had
to
know
a
lot
of
that
stuff.
A
He
had
to
know
the
operating
system,
eventually
how
to
debug
grub,
booting
errors
or
funny
I,
don't
know
Flags
when
booting
DBM
and
containers
removed
quite
a
bit
of
that
burden
and
even
more
cubic
a
vm
focus
much
around
amount
running
the
vm.
But
how
do
we
get
there?
How's
the
image
created?
How
does
the
content
get
into
the
image
tooling
was
created?
A
Guest
fish
helped
us
to
build
images,
and
we
got
other
tuning.
Our
cloud
in
it
allows
us
to
modify
content
in
a
VM
too.
To
personalize
instances,
but
that
all
grow
over
time
with
containers
that
was
a
smart
move
to
to
define
that
flow
of
how
to
create
it
and
to
run
it
they
they
did
that
very
well
and
that
attracted
developers,
because
that
burden
you
know
all
that
operating
system
burden
was
not
something
the
developers
himself
or
herself
had
to
care
about.
So
that's.
A
Why
there's
this
smaller
sentence
at
the
end,
Edwards
and
John
virtualization,
because
they
really
got
the
power
I,
should
rephrase
it
got
the
power
to
to
define
the
VM
and
developers
really
enjoy
more
containers,
because
they
don't
have
to
worry
about
the
operating
system.
They
want
to
focus
on
their
application.
A
Now
caving
koomer
were
there,
but
they
weren't
chosen
to
be
the
solution
of
the
technical
implementation
to
deliver
this
new
user
experience.
All
of
this
was
brought
to
you
by
the
new
technology
which
had
no
bugs,
and
it
was
so
so
great.
You
know
it
could
solve
everything.
It
was
brand
new,
well,
not
so
brand
new
because
it
was
picking
up.
A
Some
existing
kernel
features
like
C
groups
and
namespaces
sure
that
grow
over
time
grew
over
time
and
it's
today
much
richer
than
it
was
two
or
three
years
ago,
but
there
were
very
few
overlapping
things
between
the
virtual
machines
and
containers
now
fast
forward.
Today
we
said,
containers
came
up
and
they
dressed
use
cases.
Where
do
we
stand
today?
Actually,
after
these
two
or
three
years
of
experience,
so
today,
it's
not
that
we
have
a
single
container
running
on
a
single
host.
A
No,
instead
we
have
multiple
containers
running
and
host
and
that
not
only
you
know,
that's
not
helpful,
very
nice.
Thank
you.
We've
got
multiple
containers
running
a
single
host
and
usually
that's
not
even
useful.
So
what
appeared
is
a
container
Orchestrator
which
is
managing
a
cluster
of
hosts
for
you
to
run
containers
for
multiple
tenants,
so
actually
that
was
fast
forward
into
what
we
know
with
or
what
we
have
seen
with
the
Android.
We
have
large
just
like
OpenStack,
where
you
can
workloads
from
multiple
tenants.
A
A
Today,
it's
different
today
with
kubernetes,
with
well-defined
orchestrators,
which
can
run
containers
and
because
we're
now
running
contain
some
production.
We
also
gain
more
experience
of
how
content
is
behaving
in
production
and
people
know
people
learned
quite
a
lot
in
the
recent
years
and
and
that's
now
after
ramping
up
the
talk
and
looking,
you
know
where
containers
came
from,
that's
I
think
working
start
to
compare.
So
some
of
the
problems
we
see
in
in
production
is
that
people
realize
which
who
run
containers
workloads.
A
You
know,
can
be
insecure
right,
this
that
get
a
repository
which
somebody
committed
or
pushed
a
PR
to
and
we
merged
it.
Now.
This
is
run
on
my
hosts,
alongside
my
my
Oracle
database
or
Microsoft
database,
to
you
know,
maintaining
our
billing
or
whatever-
and
you
know,
they're
just
separated
by
namespaces.
Oh
well-
and
you
know,
I
did
I
did
that
a
shared
mount
between
these
two
namespaces.
So
how
secure
is
that,
after
all
so
people
started
to
worry
about,
you
know
the
isolation
features
of
containers?
Are
they
really?
A
Are
they
really
strict?
Are
they
a
strict?
Actually,
as
you
know,
that
other
thing
here,
how
was
it
called
KVM
cave-in
Kumu
right?
They
gave
us
a
strict
separation
between
tenants
on
the
single-mode.
Kent
containers
actually
provide
the
same
feature
set
from
that
perspective,
so
that
is
one
thing
that
really
came
up
and
and
it's
an
issue
today,
if
you
run
containers,
you
have
to
ask
yourself
what
kind
of
workload
to
are
run
on
a
node
in
in
container
and
how
do
I
separate
that?
A
A
A
I
now
do
about
this
specific
workload,
so
I'm
I
was
doing
my
kernel,
module
testing
and,
if
I
do
that
in
my
VM,
somehow
the
the
node
is
crashing
all
my
containers
whenever
there's
something
wrong
with
my
kernel,
module
or
I
got
my
my
old
application,
which
is
very
much
tuned
to
watch
a
specific
chip
said
or
or
hardware
topology
I
cannot
really.
I
cannot
really
create
that
environment
in
the
container.
Another
thing
is,
for
example,
doing
doing
testing
with
different
operating
systems.
A
So
I
want
to
test
my
agent,
which
my
company's
writing
on
Windows,
but
I
also
want
to
test
them
on
FreeBSD,
NetBSD
and
I.
Don't
know
some
UNIX,
David
or
Mac
OS
I
VMs
helped
me
to
do
that.
Containers.
Don't
help
me
to
do
that.
So
I
think
what
I
want
to
say
is
the
more
people
move
to
containers
the
more
we
see
what
containers
cannot
deliver
to
us
and
that's
where
the
community
started
to
to
to
process.
You
know
to
think
what
can
we
do
about
these
issues?
A
Please
look
at
that
circle.
You
all
want
to
and
they
process
what
they
saw
and
they
looked
at
the
problems
and
they
wondered.
What
can
we
do
about
that
and
I
mean
these
two
selected
problems:
I
just
presented
actually
just
a
subset
of
all
the
I,
wouldn't
say
problems
I
see,
but
all
of
all
the
new
things
we
learned
about
containers,
it's
just
not
that
these
two
problems
exist,
but
there
are
more
and
depending
on
where
you
come
from.
A
So
cata
containers
is
named
first
because
it's
actually
building
and
that's
written
in
the
last
line
on
three
pretty
old
projects
which
were
frankly
hyper
SH
and
clear
containers
and
they
merged,
because
we're
so
similar
and
they
actually
provide
an
isolation
layer
around
containers.
So
if
you've
got
an
untrusted
workload,
you
build
a
github
repository
right.
A
Katty
containers
tries
to
solve
that
problem
by
wrapping
this
container
in
a
QE
movie
n,
which
is
very
convenient.
They
actually
drive
quite
a
lot
of
invention
which
we'll
get
to
in
a
minute.
But
the
goal
here
really
is
to
take
a
container
and
bring
the
security
problem.
Isolation,
properties,
we
know
from
caving
Kumu
to
the
container
side.
It
has
penalties
right.
One,
big
difference
between
containers
and
VMs
is
the
boot
time.
So
how
long
does
it
take
from
the
request?
A
Until
you
have
a
really
working
environment,
you
can
work
with
and
catechin
Tainos
initially
suffered.
They
did
a
lot
of
good
work
to
to
prove
stock
well
to
fork,
stock,
qumu
and
modified
in
order
to
speed
up
the
boot
process.
A
lot
of
good
ideas
came
from
that
and
they
also
actively
work
on
the
back,
creating
these
changes
to
cumin
to
make
it
also
available
to
other
users
which
might
require
these
features
of
having
a
more
efficient
to
process
who've.
You
did
work
with
communities
before.
A
Okay,
that's
not
too
many,
but
but
a
few.
So
kubernetes
as
I
said,
is
an
Orchestrator,
and
this
is
probably
I
will
show
you
some
syntax
now
or
config
file
that
defines
how
to
run
a
container
on
communities.
So
a
reminder
for
those
who
looked
into
kubernetes
and
it's
a
general
introduction
who
to
those
who
didn't
look
into
kubernetes
in
kubernetes,
you
define
what
kind
of
workload
you
want
to
run
by
defining
the
containers
you
want
to
run.
So
your
whole
application
is
inside
such
a
container
in
general.
A
So
the
important
thing
here
is
what
we
spoke
about
early
on
that
workflow
right
we've
I
mean
the
workflow
for
user.
What
he's
running
is
still
a
container
he's
not
working
with
the
VM.
He
says:
I
want
to
run
a
container.
So
from
a
user
perspective.
If
you
think
about
what
you
would
be
doing,
it
would
still
be
building
containers.
You
would
still
be
uploading
or
pushing
containers
to
registry
and
he
would
tell
communities
to
run
a
container
in
the
background.
However,
for
you,
a
VM
would
respond
in
order
to
isolate
that
container
at
runtime.
A
A
A
container
I
might
be
repeating
myself,
so
alright,
Nexus
neighbor,
which
is
actually
pretty
pretty
fresh
name
who
is,
is
a
project
I,
don't
know
which
was
brought
up
at
last
cube
con
so
earlier
this
year
right
and
it
is
about
optimizing,
Q
EMU
for
not
necessary
for
katha
countenance
as
I
learned,
but
in
general
to
optimize
Q
more
to
to
be
more
efficient
when
it
comes
to
boot
processes,
and
that
is
supporting
kata.
Why
do
I?
Why
do
I
point
out
in
a
move
here?
A
Because
the
talk
is
about
you
know
what
impact
or
how?
What
relationship
do
we
have
got
between
containers
and
cave
in
Kumu
today,
a
name
was
the
result
of
that
containers
brought
up
the
motivation
to
look
at
queue
and
see.
What
can
we
change
in
order
to
meet
aspects
of
containers
which
we
don't
have
in
human
KVM
today,
which
is
to
be
very
efficient
at
booting?
To
be
very
quick
in
order
to
be
or
to
stay,
competitive,
yeah-
and
it
came
in
that
next
slide,
because
it
was
very
closely
related
to
cattle.
A
Alright,
another
project
which
worries
about
KVM
but
not
QE.
More
actually,
that's
interesting
here
is
g
visor.
So
g,
oh
by
the
way,
all
slides
have
that
small
paperclip
icon
down
here.
So
if
you
want
to
learn
more
about
a
specific
project,
just
click
on
that
link
in
the
slides
which
I'll
share
afterwards
in
him
and
all
the
glory
details.
A
G
visor,
as
the
prefixed
g
indicates,
was,
was
launched
by
Google
and
they
also
wanted
to
address
the
problem
of
isolating
untrusted
workloads.
So
traditionally
they
had
an
application
engine
called
App,
Engine,
Google,
App,
Engine
I,
remember
now,
and
they
wanted
to
allow
to
secure
this
workload
and
they
saw
that's
very
hard
to
do
with
pure
namespaces.
So
how
do
we
do
that
and
G
wise
is
actually
something
like
a
like
a
meta
runtime
for
containers,
because
it
has
different
backends.
A
It
has
the
sandbox
which
is
based
on
Kate,
and
so
all
the
Siskel's
are
proxied
through
KVM
in
order
to
to
secure
them.
But
there
also
is
a
different
back-end,
which
is
using
second
to
just
filter
out
the
this
is
calls
which
are
not
permitted
and
which
is
not
using
KVM,
and
then
they
have
the
proper
proprietary
approach,
if
I'm
not
mistaken,
which
isn't
the
Google
own
back-end
to
do
it
in
their
data
center.
A
Another
project-
and
this
is
project
number
one-
two
three
four
right
also
picked
up-
k,
vm,
aqm,
ooh
and
the
pattern
we
see
it's
emerging
right.
They
also
look
at
isolation,
isolating
containers
again
they
use
they
have
little
I
mean
that's
pretty
much
like
Hatter
containers
right
these.
You
just
queuing
you
and
KVM
to
launch
it
around
a
container
in
order
to
secured
the
the
approach
is
a
little
bit
different,
because
they're
focuses
on
keeping
Kumu
as
it
is.
A
So
cata
is
really
looking
at,
providing
all
the
features
in
a
very
efficient
way
so
to
pass
through
block
devices
in
order
to
get
high
performance
to
really
attach
network
interfaces
in
a
high-performing
way,
whereas
run
queue
is
more
looking
at
at
simplicity.
So
how
can
we
make
that
simple?
Also
in
order
to
make
it
portable,
because,
if
you're
always
taking,
that
is
actually
that
comes
from
the
background
of
this
IBM
z
series
from
mistaking
so
that
might
be
even
be
able
to
run
on
a
different
architecture
than
make
6864.
A
A
A
What
does
that
mean
if
we
look
at
the
definition
of
a
pod,
which
we
also
looked
at
before
you
see
that
up
here
the
definition
is
still
a
pod
right,
so
to
kubernetes.
That
would
mean
the
user
wants
to
run
a
container,
but
because
of
this
special
annotation
over
here
it
is
telling
communities
please
use
different
runtime
for
that
container,
which
happens
to
be
vert,
let
and
vert.
Let
us,
then,
interpreting
that
spec
part
of
that
pot
definition
differently.
A
So
the
image
down
here
which
a
regular
container
runtime
would
use
you
know
it
would
go
to
the
red
docker
registry
and
pull
down
the
image
and
then
run
it
inside
a
container
runtime.
What
vert
that
is
doing
it
is
actually
looking.
It
is
understanding
this
image
to
be
a
regular
cue,
cow
or
raw
image.
It
will
pull
down
that
image.
It
would
create
a
create
a
queue
in
more
instance
and
attach
that
image
wire
up
there.
A
The
best
example
is
always
locked
migration,
so
large
migration
is
one
of
these
features
we
have
in
the
virtualization
world,
who
is
not
aware
of
lack
of
migration
good
or
what
so
handle
no
live
migrations,
not
expressible,
because
live
migration
does
not
exist
in
the
container
world.
It's
an
anti-pattern
over
there
right,
so
there's
no
API
to
trigger
or
or
money
for
a
live
migration.
A
Another
thing
is,
for
example,
ballooning
or
the
type
of
graphical
interface.
You
know
the
the
kind
of
disk
bus
you
want
to
use
all
these
needy
little
features
you
need
in
order
to
make
a
VM
suited
for
specific
guest
right.
That
cannot
be
expressed
here
all
what
I
said.
It
was
not
so
true
because
in
the
end
they
do
support
to
provide
certain
configuration
options
in
a
wild-card
annotation
field.
So
you
for
certain
fields,
you
can
say
I
want
to
use
a
vertical
disk
bus
by
default
or
I
want
to
use.
A
The
benefit
is
that
to
kubernetes
running
in
vm
is
totally
transparent,
so
kubernetes
can
take
such
a
definition
and
would
treat
it
just
like
a
container,
and
that
is
helpful
because
kubernetes
has
constructs
like
replica
sets,
which
is
something
like
a
scale
group.
So
you
can
say
I
want
a
replica
set
of
this
image
and
if
you
increase
the
count
to
10,
then
you
get
10
instances
of
that
of
that
image.
A
A
A
And
then
we
have
a
little
slide
next,
one
then
with
Qbert,
oh
by
the
way,
I
always
put
logos
there,
where
project
had
a
logo
sets
and
bytes,
then
there's
Qbert,
which
is
yet
another
project
which
I
happen
to
work
on.
It
allows
you
to
run
the
images
on
kubernetes
as
well.
Using
livered
command
kbm
in
general.
Libvirt
can
be
considered
to
be
something
like
a
cluster
delivered
api
as
much
as
you
can
get
it.
A
What
does
that
mean?
So
that's
really
the
other
side
of
the
spectrum
right.
We
said,
on
the
one
hand,
side
it's
totally
transparent
to
users
that
VMs
are
used
for
isolation
purpose
here
with
Qbert.
It's
an
explicit
goal
to
to
give
the
user
the
explicit
power
to
define
what
kind
of
VM
will
be
created
so
oops.
A
So
up
here
previously
in
the
kind
we
always
saw
that
it's
about
a
pod,
a
group
of
containers
or
container
itself.
Here,
it's
a
virtual
machine
instance
and
the
definition
down
here
is
also
different.
If
anybody
of
you
has
happened
to
work
with
Liberty,
you
might
see
some
similarities,
so
you
can
really
define
the
devices
the
disks,
the
disk
buses,
the
number
of
CPU
cores,
the
CPU,
topology,
sockets
and
so
on
and
so
forth.
So
this
is
explicitly
about
defining
the
kind
of
VM
you
want
to
run
in
the
cluster.
A
A
Out
of
the
box
windows
will
not
support
the
Vertigo
bus.
You
need
to
install
the
relevant
drivers,
then
it
will,
but
out
of
the
box
it
doesn't.
There
are
some
microkernel
operating
systems
and
I
know
what
is
is
not
here,
but
they
require
explicitly
in
Vertigo
bus.
So
we
want
to
give
the
and-
and
the
stated
goal
of
Qbert
is
to
allow
to
run
every
guest
out
there,
every
with
a
little
star
which
says
as
soon
as
long
as
it's
reasonable
I
mean
there
was
a
discussion
about
machine
pipes
and
so
on
and
so
forth.
A
But
the
goal
was
to
give
the
user
the
power
to
define
the
VMS.
They
need
in
order
to
run
a
specific
guest
and
to
give
it
really
the
level
or
the
power
as
you
have
it
in
the
booth,
yeah,
so
liver
Qbert
provides
these
guest
templates
in
the
option
repository
so
that
you
can
select
fedora
or
ascent
OS
or
Windows,
and
at
the
right
API
will
be
defined
for
you
in
order
to
launch
a
given
image.
A
Yeah,
that's
the
difference,
and
here
the
stated
goal
is
to
run
to
run
him
by
the
way
you
just
not
only
run
the
VM,
but
because
it's
running
on
top
of
kubernetes
inside
a
pod
I
mean
in
the
end
the
pod
is
still
the
context
in
which
the
VM
is
running.
That
VM
can
be
integrated
with
the
other
parts
running
on
that
cluster
right,
so
it
could.
It
will
speak
to
the
same
network
and
use
the
same
storage
devices
can
use
the
same
infrastructure
just
like
all
other
containers.
A
A
Okay,
that's
it
so
far
that
were
those
aren't
all
projects
but
I
think
some,
the
large
and
active
projects,
one
important
one,
oh
well,
it's
not
so
much
and
they
know
that's
I,
think
that's
a
good
chunk
of
the
projects.
I
think
we're
like
six
of
them,
which
now
mainly
address
the
isolation
use
case
or
the
traditional
more
traditional
VMs,
which
is
actually
outlined
here.
Darn
I
should
have
taken
out
the
legacy
right.
That's
so
it
sounds
so
old,
but
awful.
It
isn't
to
summarize
so.
A
Gee
visor
cannot
contain
as
an
emu
and
run
queue
are
rather
on
the
isolation
side,
whereas
cube
root
invert.
Let
are
rather
on
this
side
to
run
VM
workloads
on
top
of
communities
and
all
of
them
really
rely
on
human
KVM
in
order
to
to
achieve
their
goal.
I
think
what
I
want
to
highlight
here
is
also
that
you
know
before
the
container
times.
This
was
really
the
target.
A
The
use
case
of
cumin,
KVM
and
I
think
what
we
saw
now
with
this
development
in
the
recent
years,
with
with
the
rise
of
these
projects,
is
that
that
KVM
and
cumin,
with
with
the
additional
tooling
actually,
you
know,
conquered
a
new
use
case,
which
is
the
container
isolation
which
is
not
just
the
isolation.
But
if
you
look
from
a
user
perspective,
it's
a
different
flow
which
allows
us
to
leverage
VMs,
and
that
is
the
container
workflow.
You
know
using
that
whole
build
chain
to
get
stuff
into
an
isolated
into
VM
environment.
A
That
is
what
we
actually
gained
from
that
change
right.
All
of
that
is
not
just
a
one-way
ticket.
So
it's
not
just
that
that
these
projects
consume
stuff
from
Qumu
KVM.
You
know
we
it's
not
just
that
they
that
it's
used
in
order
to
provide
value
to
user,
but
it's
also,
it's
actually
enriching
the
discussion
right.
So
there
are
a
few
examples.
A
C
D
A
They
they
started
with
an
IP
of
not
mistaking,
and
then
they,
you
know,
continued
that
discussion
to
see
you
know.
How
can
we
improve
that
stack
in
order
to
make
it
more
efficient?
What
can
we
do
doesn't
make
sense,
increase
improving
IP
or
are
there
odd,
I?
Think
I
now
wrote
down
vert.
If
s
it
should
have
been
NFS
of
avert
I
of
no
mistaken.
So
you
know
they
went
into
that
discussion
to
see
what
can
be
improved
and,
in
the
end,
the
traditional
virtualization
stack
gained.
A
These
features
right,
so
it's
valuable
to
other
parties,
the
traditional
uses
of
the
traditional
virtualization
solutions
as
well
like
nemu
Foster's,
the
discussion
on
fair
and
wise
devices
about
machine
x.
What
can
we
do
here
to
make
that
more
efficient?
Is
there
room
to
duplicate
some
stuff?
Is
that
really
still
needed?
A
Cubert,
for
example,
is
more
focusing
on
the
higher
level
stack.
You
know.
How
can
we
make
it
more?
How
can
we
provide?
How
can
we
do
the
VM
configurations?
Where
can
we
store
the
informations
of
how
how
a
via
needs
to
look
to
run
a
specific
guests
very
good?
How
can
we
store
that
in
a
reusable
manner
that
comes,
for
example,
from
the
Cuban
side?
And
another
thing
you
know
really
technically
bird,
which
is
also
been
done,
not
not
written
down
here.
You
know
to
break
it
up
into
smaller
components.
A
A
Even
more,
you
know
it's
making
more
vivid.
Obviously,
obviously
that
is
leads
to
changes.
So
what's
the
takeaway
in
general,
virtualization
is
here
it's
still
here.
It's
going
to
stay
I
think
that's
clear,
because
what
we
see
is
first
for
the
core
virtualization
primitives,
like
KVM
Kumu.
It
was
clear
that
this
isolation
is
something
which
is
still
desired
right,
but
also
for
VMs.
You
know
for
that
form
factor
of
vm.
I
think
it's
pretty
clear
that
this
will
also
not
go
away.
Containers
cannot
just
want
to
one
replace
VMs,
so
they
are
here
to
stay.
A
The
development
of
containers
and
the
new
insights
into
these
workflows
and
to
the
applications
which
are
running
interconnects
also
have
an
impact
on
the
KVM
ecosystem,
which
might
not
be
so
straightforward.
If
we
go
two
years
back,
it
was
not
so
clear
that
what
that
there
would
be
a
positive
impact
on
the
development
on
vert
on
the
whole
vert
stack
right,
but
in
the
end
the
new
use
cases
probably
shifted
the
requirements.
A
So
if
we
were
on
all
a
lot,
our
previous
trails
on
the
track
we've
been
on
with
the
traditional
virtualization,
we
might
have
continued
down
a
different
path.
So
all
this
container
workloads
use
cases
workflows.
They
surely
had
an
impact
which,
which
our
drivers
eventually
in
two
different
directions.
Again,
let
me
point
out
that
Nemo
Nemo
work,
which
I
think
is
a
highlight
of
how
drastic
these
new
requirements
impact
impact,
word
right
and
a
little
bit
early,
but
that
it
from
my
side
and
there's
some
room
for
questions.
A
E
E
A
A
Yeah,
so
Cubert
allows
you
to
do
that
right.
It
allows
you
to
run
VMs.
It
allows
you
to
run
VMs
alongside
alongside
containers
and
they
can
speak
to
each
other.
A
different
approach,
the
to
be
honest.
This
is
OpenStack.
Magnum
is
not
mistaken,
which
allows
you
to
run
containers
on
top
of
OpenStack,
so
there
are
different
approaches.
If
you
look
at
that
use
case,
you
know
how
can
I
orchestrate
both
VMs
and
containers
at
the
same
time,
and
then
I
would
say
cuber
today,
inverted
to
some
degree
in
OpenStack
Magnum
would
be
would
be
options.
D
Hi
a
couple
of
years
ago,
there
was
a
push
to
package
up
workloads
in
in
unique
onal
setups,
because
people
wanted
to
have
the
isolation
of
VMs,
but
have
a
single
workload
per
VM.
Do
you
have
any
view
on
where
that's
going
or
whether
that's
just
dead
in
the
water,
because
people
prefer
the
flexibility
of
the
container
type
workflow?
So.
A
I
think
if
I
understood
you
correctly,
then
I
would
say:
gee
visor
has
more
on
that
side
right,
because
dividers
really
for
a
single
application,
inputting
that
you
know
isolating
that
single
application.
That
is
the
one-to-one
mapping
a
single
application
with
KVM.
So
that
is
really
you
know,
is
that
yes,.
D
A
G
I
just
wanted
to
clarify
for
the
kind
of
question
or
the
tenant
kind
of
a
question.
It's
the
package,
granularity
that
you
would
have
is
for
a
pod,
so
you
can
have
multiple
containers
within
a
single
kind
of
e/m,
but
those
would
only
be
in
the
pod,
you
can't
just
say
like
tenant
foo
and
you
get
this
Jagan's
ovm
and
tenant
bar
the
other.
G
A
A
B
So
there
are
basically
two
basic
metrics
that
differ
between
containers
and
VMs
and
at
least
in
my
opinion-
and
this
is
startup
time
and
memory
consumption
so
startup
time
is
I
did
some
measurements
on
that
some
benchmarking,
something
like
a
penalty
of
currently
1,000
milliseconds
or
something
I
guess
you
can
reduce
this
by
some
degree.
So
this
is
pretty
fine
for
me,
but
the
memory
footprint
is
completely
different.
Do
you
see
any
progress
on
this
issue
in
the
near
future
on
this
subject,.
A
Yes,
so,
first
today,
I
would
not
take
these
two
aspects
to
compare
VMs
and
cárdenas,
but
to
answer
your
question
I,
don't
know
no
I,
actually
wonder
about
that
whole.
Was
it
pmm
stuff?
You
know
persistent
memory
where,
where
you
don't
have
that
disti
I
mean
the
problem
is
right,
which
VMs
have?
Is
that
there's
this
clear
distinction
between
RAM?
A
Well,
what
I
want
to
say
is
why
I
wouldn't
say
I
wouldn't
compare
them
until
they
do
on
these
two
objectives
is
because,
in
the
end
to
me,
really,
the
distinction
between
VMs
and
containers
is
about
the
use
of
workflows.
It's
not
it's
not
so
much
about
technical
aspects.
That's
really
I
think
we
need
to
measure
it
on
the
workflows.
That
is
what
yeah
from
a
user
perspective,
what
I
think
makes
makes
the
difference
between
them.
So.
C
Just
something
I
wanted
to
say
is
that
there
is
an
idea
of
how
to
bootstrap
like
container
like
walk
load
in
a
VM
environment.
What
you
do
is,
basically,
you
hold
a
VM
that
is
already
booted
in
suspend,
and
then
you
do
like
a
fork
memory
by
doing
a
copy
and
right
on
the
EPT,
and
this
basically
gives
you
the
container
like
experience.
If
you
and
workloads
that
are
based
on
the
same
operation
system
that
you
hold
on
the
side.
H
Overall,
the
the
the
way
people
use
containers
is
very
different
than
the
way
they
use
virtual
machines.
So
it's
it's
not
only
a
it's
not
only
about
technical
issues,
and
you
can.
You
can
reduce
boot
time.
You
can
reduce
memory
consumption,
but
there's
a
bunch
of
other
technical
aspect
that
you
have
to
manage,
which
is
how
do
I
make
a
virtual
machine?
Look
like
a
container-
and
this
is
this
is
this
is
probably
80%
of
the
work
that
we
did
with
with
carry
containers.
H
C
H
The
the
memory
consumption
question:
there's
it's
not
a
binary
thing:
it's
not
containers
bare
metal
containers
consume
less
memory
than
then
then
VM
containers
like
scatter
containers,
because
the
advantage
of
the
virtual
machine
is
that
you
control
the
the
guest
consumption
from
your
IP
visor,
whereas
with
with
docker
containers,
you
actually
don't
do
that.
You
launch
your
container
if
you
launch
1000
containers
that
do
exactly
the
same
thing.
H
So
you
can
do
many
tricks
with
with
your
hypervisor
to
reduce
that
that
memory
consumption
to
the
point
where
the
bigger
the
container
is
in
terms
of
memory
consumption,
the
the
more
interesting
it
is
to
run
it
in
in
virtual
machines,
so
the
offsets
and
the
delta
decreases
with
with
bigger
containers.
So
it's
not
a
black-and-white
answer
and
it's
not
it's
not
true.
That
containers
always
consume
less
memory
and
and
then
virtual
machine.