►
From YouTube: KubeVirt Intro: Virtual Machine Management on Kubernetes - Steve Gordon & Chandrakanth Jakkidi
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
KubeVirt Intro: Virtual Machine Management on Kubernetes - Steve Gordon, Red Hat & Chandrakanth Jakkidi, F5
This session will provide an introduction to the KubeVirt project, which turns Kubernetes into an orchestration engine for not just application containers but virtual machine workloads as well. This provides a unified development platform where developers can build, modify, and deploy applications made up of both Application Containers as well as Virtual Machines in a common, shared environment. In the session, you will learn more about why KubeVirt exists, how people are using it today, and how the project actually works from an architectural perspective. You will also see a short demo of the project in action! Finally, you will hear about future plans for developing KubeVirt’s capabilities that are emerging from the community.
https://sched.co/VyBC
A
All
right,
my
name
is
Stephen
Gordon.
Today
we're
going
to
be
giving
you
an
introduction
to
Qbert
Qbert
is
a
project
which
is
aiming
to
bring
virtual
machine
management
into
kubernetes,
so
I'm
a
product
manager
at
Red,
Hat
based
out
of
Toronto
Canada.
My
team
is
primarily
responsible
for
what
we
call
kubernetes
native
infrastructure,
which
is
effectively
trying
to
look
at
what
we're
learning
about
managing
applications
in
kubernetes
and
seeing
how
we
can
apply
that
to
infrastructure
software
problems,
one
of
which
is
how
do
we
manage
virtual
machines?
I.
B
Hope
you
you
hear
me
know
so.
As
I
said,
I'm
Chandra,
I
work
for
a
finite
works
as
a
senior
software
engineers
presently
working
for
continuing
English
service
project.
So
basically
it
is
English
controller
and
bringing
container
applications
into
the
ecosystem
and
providing
alpha
to
f7
services,
and
apart
from
that,
it
will
have
application
services
like
graph
and
providing
better
security
and
previously
started
from
OpenStack
I,
have
a
active
user
contributor
and
now
kubernetes
and
projects
like
Qbert
previously
worked
with
Cisco
and
other
companies.
So
this
is
my
short
introduction.
B
A
So,
as
I
mentioned
at
the
outset,
the
goal
of
Qbert
is
to
turn
kubernetes
into
a
single
Orchestrator
for
containers
and
virtual
machines,
and,
of
course,
kubernetes
is
already
pretty
good
at
the
application
container
side
of
that
equation.
So
really
we're
focused
on
the
virtualization
piece
and
how
we
can
bring
virtualization
and
virtual
machines
into
that
ecosystem.
A
Qbert
started
as
a
POC
at
Red
Hat
in
2016.
We
really
only
started
getting
serious
about
the
project,
though
in
January
2017,
which
is
when
we
actually
open
sourced
it
and
create
the
open
source
project
which
is
Apache,
2.0
licensed
recently
I.
Think
in
September
it
was
accepted
into
the
cloud
native
computing
foundation
sandbox
as
a
project
there.
A
So,
in
terms
of
our
progress
on
that,
you
can
see
just
some
rough
stats
here,
all
the
usual
things
around
growth
in
commits
stars
on
github
all
that
kind
of
stuff.
The
thing
we're
really
looking
at
continuing
to
drive
is
increasing
that
sweat
of
non
Red
Hat
code
contributors.
So
if
you
look
at
it
right
now,
it's
probably
about
a
third
of
the
contributors
in
on
Red
Hat.
A
We
want
to
see
that
continue
to
increase
on
the
right
hand,
side
we've
listed
some
of
the
users
and
contributors
from
other
organizations
which
came
out
and
supported
the
sandbox
application
recently.
So
you,
when
you
look
down
these
columns,
those
on
the
left
with
the
checkmarks
people
were
using
Cubert
today
and
those
on
the
right
of
those
are
actually
contributing
to
Cubert
itself
or,
if
the,
if
the
check
is
in
brackets,
that
means
they're
contributing
to
one
of
the
adjacent
projects.
So,
under
the
overall
Cuba
banner,
we
have
another
number
of
adjacent
utilities.
A
A
So
why
cube
why
this
desire
to
bring
virtual
machines
into
kubernetes?
So
one
when
we
started
the
project?
We
certainly
already
saw
back
in
2016-2017.
The
growing
velocity
behind
kubernetes
and
the
surrounding
ecosystem
is
the
place
that
people
were
increasingly
looking
to
build
and
deploy
new
applications.
But
we
also
realized
the
that
most
people
in
their
organizations
have
virtual
machines
that
they're
going
to
need
to
deal
with
in
various
ways
for
many
years
to
come.
A
So
we
really
wanted
to
focus
on
how
do
we
build
transition
paths
for
those
users
with
those
virtualization
workloads,
as
their
mix
of
virtual
machines
and
containers
changes
over
time
and
also
to
assist
people
who
may
want
to
decompose
a
virtualized
application?
But
it's
going
to
take
them
a
little
while
to
do
so,
and
they
want
to
do
that
within
a
common
development
environment
in
terms
of
what
applications
are
harder
to
containerize.
A
So
we
really
here
a
focus
on
both
some
technical
reasons,
so
certainly
we're
cognizant
of
the
fact
that
many
virtual
machines,
particularly
even
appliances
you
may
be
getting
from
another
vendor-
have
limitations
in
terms
of
what
is
the
operating
system
running
inside
that
virtual
machine
and
and
that
that
application
is
certified
on.
So
that's
why
we
are
focused
on
being
able
to
run
operating
systems
going
back
to
the
rl6
kernel
versions.
A
Just
to
give
you
a
rough
idea
of
kind
of
timeline
of
those
linux
versions,
we
can
support,
but
also
going
back
to
Windows,
Server,
2012
and
above
to
be
able
to
support
those
workloads
that
run
on
those
as
well
now.
The
other
reason
that
things
might
be
hard
at
harder
to
contain
arises,
of
course,
business
reasons
in
terms
of
just
time
to
market
and
the
cost
of
conversion
compared
to
the
relative
return
on
investment.
A
So
I
want
to
talk
a
little
bit
about
some
of
the
use
cases
we're
seeing
in
the
community.
So
certainly
one
of
the
use
cases
is
simply
I
have
some
existing
functionality
in
my
organization,
that's
running
in
a
virtual
machine
but
I'm
building
new
business
functionality
around
that
in
application
containers,
so
I
want
to
pull
that
existing
virtual
machine
into
my
communities
based
development
environment.
So
I
can
work
on
those
components
of
my
applications,
side
by
side
and
use
the
same
CI
pipelines
and
so
on.
A
They're
a
little
different
to
the
first
two
is
as
a
way
to
run
kubernetes
in
what
I
would
call
the
clustering
cluster
configuration
and
by
that
I
mean
organizations
who
want
to
create
a
separation
between
what
they
consider
is
their
infrastructure,
kubernetes
cluster
and
the
kubernetes
clusters
that
they're
handing
out
to
development
teams,
or
even
in
some
cases,
individual
developers.
So
what
Qbert
is
providing
in
that
context
is
hard
multi-tenancy
between
those
developer
facing
criminales
clusters
and
the
way
that
works
is
using.
A
A
The
final
use
case
I
just
wanted
to
touch
on
because
we
also
see
this
from
some
of
our
community
users,
and
actually
it
was
a
topic.
At
least
the
part
of
the
discussion
at
the
community
meetup
this
morning
is
the
idea
of
bringing
in
virtual
network
functions
and
other
virtual
appliances
to
kubernetes.
So
for
those
who
are
not
familiar,
virtual
network
functions
is
the
idea
which,
as
a
communication
service
provider,
typically
I,
have
some
aspect
of
my
network,
which
is
effectively
living
in
a
virtual
machine.
A
So
in
terms
of
just
some
high-level
features
and
we'll
go
into
this
a
lot
more
detail
in
some
of
the
technical
information
in
a
second,
but
at
a
high
level,
we're
aiming
to
provide
a
API
for
defining
virtual
machines
managing
virtual
machines.
We
do
that
as
part
of
kubernetes
by
implementing
custom
resource
definitions.
A
So
we
have
a
number
of
top-level
custom
resource
definitions,
including
the
obvious
one,
for
a
virtual
machine,
but
also
a
couple
of
others
for
various
aspects
of
the
virtual
machine
storage
and
also
for
things
like
the
idea
of
a
replica
set
that
includes
virtual
machines
and
so
on.
By
implementing
this
functionality
as
custom
resources,
we
do
gain
a
lot
of
automatic
integration
with
the
Kuban
areas
ecosystem.
So
we
do
gain
integration
with
cluster
level
features.
A
So
my
virtual
machines
running
on
qubit
connecting
to
the
same
container
networking
interface
plugins
as
my
app
container
so
they're
on
the
same
network
on
the
pod
network,
at
least
they're,
connecting
into
the
same
storage
drivers
using
the
container
storage
interface
and
so
on,
and
we
also
gain
node
level
features.
So
I
kind
of
alluded
to
this
in
the
vnf
use
case,
but
we
are
still
using
both
for
our
virtual
machines
and
our
app
containers,
the
same
CPU
manager,
the
same
multi
network
provisions,
multi
network
aspects.
A
And
typically,
that
means
the
way
that
will
work
for
both
App
containers
and
virtual
machines,
because,
typically,
whatever
app
it
is
running
in
someone's
virtual
machine
today
they
are
going
to
have
an
app
in
the
future.
That
has
some
a
similar
requirement
when
it's
running
in
a
container,
so
if
it
needs
a
special
device
or
some
special
logic
around
how
we
place
that
workload
appropriately,
we
want
to
think
about
how
we
can
make
that
work
for
App
containers
in
the
future
as
well.
A
So
before
we
dive
a
little
deeper,
you
know
if
you've
already
heard
enough-
and
you
just
wanted
to
get
started
at
Cubert-
that
IO
there
are
a
number
of
getting
started
paths.
So
there
is
the
catechu
de
learning
paths,
but
also
if
you
wanted
to
spin
up
a
cluster
with
keep
it
on
it
yourself,
there
are
buttons
there
to
start
with
mini
cube,
Amazon
or
Google
Cloud.
A
The
one
thing
I'll
mention
with
the
public
cloud
options
here
is
that
they
are
running
Qbert
in
a
nested
virtualization
scenario,
which
is
not
what
we
would
typically
see
in
real
use.
So
in
real,
you
swim
and
typically
expect
that
someone's
running
Qbert
on
a
bare-metal
cluster,
regardless
of
whether
it's
private
public
whatever
but
for
just
getting
started
and
kind
of
getting
used
to
the
interface
and
so
on
running
it
in
Nesta
is
fine,
so
feel
free
to
go
and
kick
the
tires
on
that.
B
Yeah
thanks
that
was
a
nice
introduction,
so
I
think
now
you've
got
some
idea
about
what
is
Q
board
so
now
we'll
get
a
little
bit
more
about
Q
board.
So
the
agenda
of
technical
enter
is
just
go
through
the
virtualization
stack
and
then
what
actually
are
the
current
scenarios
and
what
is
the
environment
we
need
and
how?
What
is
going
to
solve
that
and
little
bit
introductions
about
the
architecture
and
the
components
we
use
and
then
followed
by
a
short
demo.
B
So
it's
like
between
5
minutes
how
to
bring
up
the
Q
word
installation
and
just
bring
up
your
virtual
machines.
So
it's
a
short
demo
and
if
time
permits
I
will
give
you
that
one
should
like
networking
feature
networking
more
as
well.
So
so
we
know
that
this
is
a
typical,
an
expostulation
stack
where
we
have
a
very
metal.
On
top
of
that
we
have
a
hypervisor
like
a
VM,
and
now,
on
top
of
that,
we
are
spinning
up
our
virtual
machines.
So
we
are
for
software
oscillations.
B
We
are
using
cam
and
hardware
virtualization,
so
we
are
using
hypervisor
like
KVM
so,
but
when
you
want
to
run
VMs
I
said
Steve,
we
should
have
some
kind
of
mechanism
where
we
are
running.
We
are
not
running
containers
in
the
VM,
we
are
running
v,
we
are
launching
VMs
in
the
container.
So
this
is
a
typical
scenario
where
we
have
to
take
care.
The
virtualized
stack
within
the
container
ideation
stack.
So
what
how
it
is
going
to
be?
You
know
we
are
integrating
the
modulation
stack
into
the
continuation
stack.
B
So
this
is
a
typical
diagram,
how
it
looks,
but
who
is
going
to
solve
this
problem?
So
basically
a
cube
word
approach.
This
approach,
the
cube
board-
will
be
installed
in
the
master
as
a
controller
and
it
has
a
API
server
and
the
agent
will
be
running
in
the
worker
nodes.
So
it
will
be
talking
to
the
both
virtualization
stack
as
well
as
the
container
environments,
and
then
it
is
like
this.
B
We
can
bring
both
virtual
machines
and
containers
in
the
same
environment
because
the
enterprise
applications
which
are
running
for
decades
in
the
virtual
in
the
VMs
or
who
have
virtual
editions
as
their
solutions.
They
cannot
simply
migrate
to
the
containers,
but
the
companies
who
born
in
the
cloud
that
is
easy
and
the
development
going
on
in
the
current
is
in
the
container
space.
But
the
companies
which
are
using
there
are
solutions
in
the
virtual
space
they
cannot
migrate
easily.
There
should
have
it,
you
know
really
two
environments
to
support
their
solution.
B
Space,
which
is
hard
to
maintain,
as
well
as
the
Magnusson
part,
is
also
very
a
complex.
Whereas
if
you
have
a
you
know,
environment,
where
we
can
run
our
virtualization
solutions
and
the
containerization
solutions,
which
is
a
future
or
the
current
development,
and
then
we
can
slowly
migrate
to
the
containerized
world,
then
it
is
going
to
a
solve
the
problem
because
we
are
in
the
same
space
and
we
are
using
a
one
environment.
So
that
is
how
q
board
is
approached
and
it
it
has
a
different
components.
B
I
will
explain
in
the
next
coming
slides,
but
this
is
a
basic
architecture.
It
has
a
controller,
it
has
a
API
server
and
it's
a
agent
running
in
the
worker
nodes.
So
basically
we
can,
you
know,
divide
the
keyboard
into
this
multiple
components
like
API
server.
What
launcher
and
the
word
controller
just
we
have
seen
the
previous
diagram
and
what
handler
and
also
we
are
using
liebert
live
board
d,
so
we
will
go
through
one
by
one.
B
The
one
thing
I
would
like
about
the
q''-word
is:
it
is
always
the
design
pattern
is
always
keeping
in
mind
the
Katyn
K
native,
so
they
always
don't
want
to
be
a
virtual
machines
treated
as
like
what
in
the
virtual
is
in
space.
They
also
want
to
use
the
kubernetes
native
applications
like
a
pas
and
cre
CR
DS.
So
this
API
server
supports
the
kind
virtual
machines.
B
This
is
a
major
component
because,
with
the
help
of
Liberty,
only
we
are
able
to
you
know,
launch,
run
the
VMS
in
the
container
container
space.
So
what
why
we
are
using
Leibert
is
it
supports
vast
variety
of
hypervisors
like
a
VM,
Xen
and
VMware
hypervisor.
Also,
it
supports
other
operating
systems
so
because
Liberty
is
a
proven
technology
and
it
uses
it
supports
almost
all
kind
of
virtualization
stack.
So
liquid
is
a
also
one
of
the
main
components
of
the
keyboard
we
are
using.
B
We
are
just
leveraging
the
advantage
of
the
Liberty
here
so
when
it
comes
to
the
actual,
you
know
how
the
action
part
the.
What
launcher
is
the
key
component,
and
it's
just
pod,
when
you
install
when
you
trying
to
you,
know
bring
up
a
virtual
machine,
what
launcher
pod
will
come
and
then
it
will
have
the
information.
What
is
going
to
be
done?
What
kind
of
virtual
machine
you
are
going
to
spin
up?
So
what
this?
This
will
have.
Two
components
like
it
will
spin
up.
B
One
is
a
volume
controller,
it
can
be
a
PVC
volume
controller
or
it
can
be
a
container
disk
or
any
physical
disk,
or
it
can
be
a
compa.
So
when
you
have
given
a
virtual
machine
image,
so
watch
launch
pod
will
kick
off
and
then
it
will
kick
the
clipboard
a
and
then
the
what
will
they
do?
What
we
Liberty
daemon
will
be
in
action
and
it
will
spin
up
the
VM.
Just
like
you
are
spinning
up
the
VM
in
in
the
actual
systems.
B
B
You
know
applicable
to
the
VM
as
well,
and
it
will
be
able
to
communicate
with
the
other
ecosystem.
That
is
the
containers
from
the
VM.
So
we
are
using
a
simple
techniques
and
with
the
help
of
l2
utilities,
we
are
communicating
the
VM
from
from
the
VM
to
the
container.
So
the
the
basic
networking
and
I
will
see
the
advanced
part
next.
So
the
other
part
is
it's
a
what
controller?
It's
it's.
Basically,
it's
a
controller
for
each
and
every
object
like
if
you
have
a
defined
for
virtual
machine.
B
It's
not
going
to
be
kick
off.
We
are
not
directly
going
to
okay
launch
the
virtual
machine
before
that
will
give
the
virtual
machine
instance.
It
is
just
like
for
OpenStack
people
the
flavour,
so
what
we
have
different
the
flavor
is
nothing
but
a
virtual
machine
instance
and
with
the
help
of
virtual
machine
instance,
the
butt
launcher
will
know
what
kind
of
VM
it
is
going
to
be
spin
up
and
then
actual
VM
is
going
to
be
a
launch.
B
So
all
these,
like
advanced,
are
like
advanced
to
the
components
like
replica
set
unknown
migration
will
be
having
some
set
of
dependencies
and
each
will
be
have
controlled
by
the
word
controller.
So
what
controller
will
control
and
it
will
have
the
communication
between
the
world
VM
ice
and
VM
kind
of
thing.
B
So
the
final
one
is
what
handler
the
the?
What
handler
basically
is
interface
between
the
word
controller
and
the
word
launcher,
whereas
what
controller
is
having
the
information
about
the
VM
specifications
and
all
the
word
launcher
will
see
whether
all
components
are
running
properly
or
not.
So
once
the
part
is
running
virtual
on
chip
pod
is
running,
then
it
will
kick
off
the
actual
VM.
So
it
also
handles
the
lifecycle
management
of
the
VMs,
which
is
not
actually.
We
cannot
have
this
lifecycle
management
for
containers.
So
this
is
one
of
the
advantage.
B
If
you
run
virtual
machines
in
the
you
know,
these
containers-
you
can
always
just
predefined
in
the
dormant
state,
and
you
can
start
stop
and
you
can
just
delete
in
you
can
update.
So
all
this
can
be
possible
with
the
word
handler,
so
it
it
supports
all
kind
of
lifecycle,
management
for
virtual
machines.
So
with
that
I
have
just
given
a
short
architectural
interview,
architectural
interaction
to
the
cube,
but
now
we
will
see
the
demo
part.
B
B
The
predictor
site
is,
you,
can
should
have
any
kind
of
cluster,
whether
it
is
a
mini
Q.
Also,
fine,
you
should
have
a
master
running,
that's
that's
a
pretty
excite
and
then
I'll
just
going
to
give
the
late
I'm
going
to
take
the
latest
version
of
the
Q
word
and
then
so.
This
is
the
we
can
take
from
the
github
repository.
B
B
B
Thank
you,
okay.
So
next
step
is
we
are.
We
are
installing
the
cube
word
CR
and
there
is
a
custom
resource
and
that
is
actual
bring
up
all
the
components
of
the
cube
word.
Just
now
we
have
discussed
it
will
bring
up
or
what?
What
launcher
and
what
Handler?
What
controllers
so
now
I
will
see
now
I'm
going
to
install
the
word
custom
resource
and
it
is
pinning
up
all
the
ports
first,
it
is
bringing
up
the
API
server
and
then
it
is
bringing
up.
B
B
I
will
see,
then
bringing
up
a
basic
vm
which
is
like
we
can
take
up
0s
image
just
like
because
it
it
is
a
lightweight
vm
and
it
is
good
for
you
know
it
will
spin
up
just
like
that
and
I'm
using
a
but
I
have
just
now
installed
the
what
a
controller
that
is
actually
used
for
lifecycle
management.
So
this
is
the
you
know:
a
mill
fella
I
am
using.
B
This
is
kind
virtual
machine
and
the
name
is
test
VM
and
I'm,
just
bringing
up
I'm
assigning
some
memory
and
the
container
disk
image
I
am
using,
but
it's
a
remote
and
I'm
taking
from
the
repository
0s.
So
it's
like
it's
using
cloud
in
it,
so
we
can
take
advantage
of
the
all
the
coordinate
scripts
we
have
so
now.
I
will
spin
up.
This
I
will
apply
this
ml
file
and
I
will
try
to
bring
up
the
VM.
B
So
I
just
to
apply
that
EML
file
and
before
it
will
not
bring
up
the
VM,
but
the
states
the
status
e
is
false.
So
what
we
can
do
is
we
can
just
start
the
VM
and
we
can
using
what
CTL
command.
We
can
I
just
started
the
VM
and
now
we'll
see.
Actually
the
VM
is
in
the
running
state
or
not
and
yeah.
It
is
running
now
so
I'm,
just
logging.
You
can
use
what
CTL
console
command
to
log
into
the
VM,
because
we
have
just
pinned
up.
It
is
taking
some
time.
B
So
here
we
go
yeah,
okay,
so
it's
not
even
5
milliseconds,
so
we
have
just
learn
today
we
have
installed
a
cuboid
and
we
have
installed.
We
have
brought
up
a
VM
as
well,
so
good
thing
is:
they
are
running
side
by
side.
We
can
and
yeah
it.
Basically,
it
is
having
only
one
interface.
There
is
a
part
network
and
yeah.
It
is
able
to
ping
the
extra
network
as
well.
So
that's
a
that's
a
that
is
past
demo,
so
whoever
want
to
have
hands-on
and
get
to
know
about
the
cuboid.
B
B
So
next
this
is
like
for
the
VMS
who
need
multiple
interfaces.
This
problem
we
have
when
we
are
bringing
up
the
containers
but
virtual
machine.
Is
this
a
basic
feature?
So
when
we
are
bringing
up
when
we
want
to
bring
up
a
virtual
machine
with
multiple
interfaces
that
is
not
supported
presently
because
of
the
limitation
which
we
we
have
only
the
CNA,
the
plan'll
will
have
only
one
interface,
but
that
can
be
solved
using
the
Malta.
So
now
you
can
see
here,
I
have
a
ml
file,
which
is
virtual
machine
instance
and
I.
A
B
So
before
going
for
the
demo,
we
want
to
have
a
short
introduction
about
what
is
Malta,
so
multi-sexual
e
it
an
arbitrator
to
bring
up
multiple
CNAs
so
for
the
applications
which
need
multiple
interfaces,
we
can
install
Malta
and
we
can
specify
what
in
network
interfaces
can
be
treated
as
a
Maltese
and
that
interfaces
can
be.
You
know
connected
to
the
other
side
of
the
containers
talking
to
the
external
wall
or
management
IP
or
management
writer,
whatever
the
needs
based
on
based
on
the
networking
part.
B
So
this
is
one
thing
and
that,
when
I
started
exploring
this
cuboid
project,
one
primary
problem
I
have
faced
is
uploading.
The
images
customized
application
eyes
images,
because
VM
images,
just
now
we
have
shown,
is
that
we
couldn't
take
my
0
s
image
our
center
image.
We
can
take
them
take
from
the
cloudy
cloud
images,
but
when
you
want
to
bring
up
your
own
image
right,
you
should
the
customized
applications
you
want
to
have
it
in
the
local
disc,
so
I
found
this.
You
know
darkest
Barker
command
is
very
much
useful.
B
You
just
you
know,
make
images
container
images
using
aq.koh.
Two
images
like
VM
images
and
just
upload
it
to
the
local
container
disk
and
your
image
content
image
is
ready.
So
apart
from
that,
you
can
use
persistent
disk
like
PVCs
and
PVS,
but
if
you
want
to
have
a
you
know,
explore
quickly
and
bring
up
your
own
application
or
own
VM,
and
you
can
upload
it
to
the
container
disk
and
you
can
just
start
using
it.
B
So
that's
what
we
are
doing
here
so
I
have
just
uploaded
that
centrist
to
my
local
registry
and
then
I'm,
calling
that
I'm
pulling
that
image
with
this
command.
So
it's
as
simple
as
that
and
then
I
have
defined
my
specifications
like
memory
and
all
CPU
and
now
coming
to
the
interface
part.
Previously
we
have
shown
only
one
interface.
Now
we
can
see
the
two
three
interfaces:
basically
network,
one
network
2
and
the
power
interface
pod
interface.
Now
now
we
will
talk
about
this
port
interface
and
how
also
define
the
network
kings.
B
So
here
the
network
1,
is
my
application
network
1
and
the
network.
2
is
in
my
application,
which
were
to
for
different
purposes
and
the
port
network
I'm,
not
specifying
any
network
so
that
it
can
use
the
default
in
that
support
network,
in
this
case
I'm
using
a
flannel
Network
and
for
other
to
bring
up
other
networks
I'm
using
a
poultice
Network.
So
this
is
my
typical
ml
file.
Through
this
I
can
bring
up
multiple
interfaces.
I
can
start
using
multiple
networks.
B
Ok,
so
there
is
a.
There
is
a
one,
interesting
thing:
when
you
bring
up
your,
you
know:
application
with
multiple
interfaces
right
if
some
some
applications,
the
default
interface
is
poor
network.
That
is
e0,
but
if
you
want
to
use
your
own
network
like
management
network
as
a
8
0
that
is
overwritten
by
the
pollinator
because
of
the
default
behavior.
B
So
this
is
my
CentOS
VM
and
my
customized
CentOS
VM
and
yeah.
So
here
you
can
see
all
the
three
interfaces
which
is
like
Ichiro
is
my
management
to
network
and
each
one
is
a
port
Network,
and
it
too
is
your
four
other,
like
external
network,
a
public
network.
So
with
this
I
mean
with
this
demo,
I
think
we
have
completed
the
networking
part
I
think
we
should
have
some
space
for
questions
so
yeah.
Sorry,
we
have
a
lost,
slides
I,
will
hand
it
over
to
the
Steve
again
yeah.
A
All
right
so
just
quickly
in
terms
of
future
plans
in
a
sooner
it's
a
later
rough
order,
so
I
mentioned
kind
of
the
core
goal
is
to
be
able
to
run
traditional
virtual
machines
that
people
already
have
in
many
cases.
That
means
better
support
for
workloads
that
are
exactly
exacting
from
a
determinism
or
performance
standpoint,
so
certainly
improvements
around
CPU,
pinning
new
motor
policy
management,
IO
thread
pinning
all
these
things
also
things
we're
trying
to
improve
in
kubernetes
for
general
application
container
workloads.
A
So
that
ties
in
quite
well
with
things
that
are
happening
in
the
broader
community.
We
are
also
looking
to
take
advantage
of
storage,
assisted
snapshots
and
cloning,
particularly
this
becomes
useful
if
you
think
about
an
end-to-end
flow,
where
you
wanted
to
take
a
backup
of
a
virtual
machine,
and
you
have
some
underlying
storage
subsystem
that
can
assist
you
with
that
by
and
performing
it
at
a
performant
manner.
A
We're
also
looking
at
forensic
virtual
machine
capture.
Gpu
pass-through
is
out
of
actually
out
of
order
here,
so
Nvidia
have
contributed
GPU
pass-through
in
a
recent
recent
release,
so
that
is
there
now
as
well,
although
we're
still
finalizing
some
of
the
documentation
around
that
policy-based,
Life
migration
and
additional
live
migration
modes
and
finally,
hot
plugging
is
something
that
we're
interested
in
for
some
of
these
traditional
workloads
as
well
again
in
terms
of
the
kubernetes
native
approach.
A
Many
of
these
things
areas
where
we're
trying
to
improve
kubernetes
as
well,
not
just
the
cube
project
on
top
of
it.
So
for
those
who
want
to
go
deeper,
there
is
a
kiva
deep
dive
session
tomorrow,
1055
that'll
be
in
room
1,
a
B,
and
some
of
the
engineering
folks
who
are
contributing
directly
to
the
project
will
be
doing
that
deep
dive
session.
A
A
We
have
VNC,
we
do
not
have
spice
because
spice
and
the
number
of
ports
it
uses
poses
some
interesting
challenges
from
cuban
areas
networking
perspective,
but
we
also,
if
you're,
running
a
Windows
VM,
you
can
expose
the
RDP
port
as
a
kubernetes
service,
and
that
works
just
fine
as
well
any
others
quickly.
Yep.
A
Can
you
throw
live
bird
xml's
at
it?
No,
although
you'll
find
the
top
level,
API
definition
for
Cubert
is
very
similar
to
the
libertines
definition,
so
you
could
translate
it
relatively
easily
that
way,
but
we
don't
currently
have
a
way
where
it
will
just
ingest
a
little
bit
XML
domain
as
it
exists
today.