Openstack Super Bootcamp PDF

OpenStack
Super
Bootcamp
Mirantis, 2012
Agenda
OpenStack Essex architecture recap
Folsom architecture overview
Quantum vs Essex's networking model
Initial State
Tenant is created, provisioning
quota is available, user has an
access to Horizon/CLI
Horizon
CLI
Keystone
nova: Cloud Controller

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 1: Request VM Provisioning via UI/CLI

User specifies VM params:
name, flavor, keys, etc. and hits
"Create" button
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 2: Validate Auth Data

Horizon sends HTTP request to
Keystone. Auth info is specified
in HTTP headers.
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 2: Validate Auth Data

Keystone sends temporary
token back to Horizon via HTTP.
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 3: Send API request to nova-api

Horizon sends POST request to
nova-api (signed with given
token).
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 4: Validate API Token

nova-api sends HTTP request to
validate API token to Keystone.
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 4: Validate API Token

Keystone validates API token
and sends HTTP response with
token acceptance/rejection info.
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 5: Process API request

Horizon
nova-api parses request and

validates it by fetching data from
nova-db. If request is valid, it
saves initia db entry about VM
to the database.
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 6: Publish provisioning request to queue

Horizon
nova-api makes rpc.call to

scheduler. It publishes a short
message to scheduler queue
with VM info.
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 6: Pick up provisioning request

scheduler picks up the message
from MQ.
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 7: Schedule provisioning

Horizon
Scheduler fetches information

about the whole cluster from
database and based on this info
selects the most applicable
compute host.
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 8: Start VM provisioning on compute node

Horizon
Scheduler publishes message

to the compute queue (based on
host ID) and triggers VM
provisioning
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 9: Start VM rendering via hypervisor

Horizon
nova-compute fetches
information about VM from DB,
creates a command to
hypervisor and delegates VM
rendering to hypervisor.
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 10: Request VM Image from Glance

hypervisor request VM image
from Glance via Image ID
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 11: Get Image URI from Glance

If image with given image ID
can be found - return
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 12: Download image from Swift

Horizon
hypervisor downloads image

using URI, given by Glance,
from Glance's back-end. After
downloading - it renders it.
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 13: Configure network

nova-compute makes rpc.call to
nova-network requesting
networking info.
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 14: allocate and associate network

nova-network updates tables
with networking info and VM
entry in database
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Step 15: Request volume attachment

Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Initial State
Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Still part of nova

Horizon
CLI
Keystone

nova-api
Glance
endpoint
glance-api
glance-registry
scheduler
nova: Compute
nova-db
nova-compute
nova-network
nova-volume
que
ue
Shared Storage
hypervisor
Swift
proxy-server
object
store
Limitations?
Nova is "overloaded" to do 3 things
Compute
Networking
Block Storage
API for networking and block storage are still

parts of nova
Keystone
UI: horizon or CLI
keystone
server
nova
compute node
controller
queu
e
nova-api
nova:
novaCompute
Hypervisor
compute
Quantum
V
M
scheduler
keystone
-db
quantum
server
nova-db
Network
quantum
-db
Cinder
endpoint
scheduler
cinder-db
queu
e
cinder-vol
block
storage
node
glance-api
storage
glance-registry
Glance
quantum
plugin
Swift
proxy-server
glance
db
object
store
Keystone
UI: horizon or CLI
keystone
server
nova
compute node
controller
queu
e
nova-api
nova:
novaCompute
Hypervisor
compute
Quantum
V
M
scheduler
keystone
-db
quantum
server
nova-db
Network
quantum
-db
Cinder
endpoint
scheduler
cinder-db
queu
e
cinder-vol
block
storage
node
glance-api
storage
glance-registry
Glance
quantum
plugin
Swift
proxy-server
glance
db
object
store
Essex' networking model overview
single-host vs multi-host networking

the role of network manager
different network manager types
floating IPs
Revisit of KVM networking with linux bridge
router
router: 10.0.0.1
(def. gateway for VMs)
VM
10.0.0.2
nova-compute host
VM
10.0.0.4
VM
10.0.0.3
VM
10.0.0.5
linux
bridge
linux
bridge
eth0
eth0
switch
nova-compute host
Single-host networking
KVM host == nova-compute

router == nova-network
eth1
public ip
routing/NAT
eth0
nova-network host
eth0 IP:10.0.0.1
(def. gateway for VMs)
VM
10.0.0.3
VM
10.0.0.4
VM
10.0.0.2
nova-compute host
VM
10.0.0.5
linux
bridge
linux
bridge
eth0
eth0
switch
nova-compute host
What happens if nova-network host dies

VM:~root$ ping google.com
eth1
No route to host
routing/NAT
eth0
VM
10.0.0.2
nova-compute host
VM
10.0.0.4
VM
10.0.0.3
VM
10.0.0.5
linux
bridge
linux
bridge
eth0
eth0
switch
nova-compute host
Multi-host networking
Move routing from the central server
to each compute node independently to
prevent SPOF.
eth1
routing/NAT
eth0
public ip
public ip
eth1
eth1
routing/NAT
routing/NAT
VM
10.0.0.2
nova-compute &
nova-network host
VM
10.0.0.4
VM
10.0.0.3
VM
10.0.0.5
linux
bridge
linux
bridge
eth0
eth0
switch
nova-compute &
nova-network host
Multi-host networking
Compute servers maintain Internet access independent from each other. Each of
them runs nova-network & nova-compute components.
public ip
public ip
eth1
eth1
routing/NAT
routing/NAT
VM
10.0.0.2
10.0.0.1(gw)
VM
10.0.0.4
VM
10.0.0.3
linux
bridge
10.0.0.6(gw)
linux
bridge
eth0
eth0
nova-compute &
nova-network host
VM
10.0.0.5
switch
nova-compute &
nova-network host
Multi-host networking - features

Independent traffic:
Instances on both compute nodes access external
networks independently. For each of them, the local linux
bridge is used as default gateway

Routing:
Kernel routing tables are checked to decide if the packet
should be NAT-ed to eth1 or sent via eth0

Routing:
Kernel routing tables are checked to decide if the packet
should be NAT-ed to eth1 or sent via eth0
IP address management:
nova-network maintains IP assignments to linux bridges

and instances in nova database
Network manager
Determines network layout of the cloud
infrastructure
Capabilities of network managers
Plugging instances into linux bridges

Creating linux bridges
IP allocation to instances
Injecting network configuration into instances
Providing DHCP services for instances
Configuring VLANs
Traffic filtering
Providing external connectivity to instances
FlatManager
Features:
Operates on ONE large IP pool. Chunks of it are shared between tenants.

Allocates IPs to instances (in nova database) as they are created
Plugs instances into a predefined bridge
Injects network config to /etc/network/interfaces
eth1
eth1
VM
VM
/etc/network/interfaces:
"address 10.0.0.2
gateway 10.0.0.1"
linux
bridge
linux
bridge
eth0
nova-compute &
nova-network
eth0
nova-compute &
nova-network
10.0.0.1(gw)
FlatDHCPManager
Features:
Operates on ONE large IP pool. Chunks of it are shared between tenants

Allocates IPs to instances (in nova database) as they are created
Creates a bridge and plugs instances into it
Runs a DHCP server (dnsmasq) for instances to boot from
eth1
VM
eth1
VM
obtain dhcp static lease:
ip: 10.0.0.2
gw: 10.0.0.1
dnsmasq
eth0
nova-compute &
nova-network
linux
bridge 10.0.0.1(gw)
eth0
nova-compute
& nova-network
DHCP server (dnsmasq) operation
is managed by nova-network component

in multi-host networking runs on every compute node and
provides addresses only to instances on that node (based
on DHCP reservations)
eth1
VM
ip: 10.0.0.4
gw: 10.0.0.3
dnsmasq: static leases for

10.0.0.4 & 10.0.0.6
eth1
VM
ip: 10.0.0.6
gw: 10.0.0.3
linux
bridge
10.0.0.3(gw)
VM
ip: 10.0.0.5
gw: 10.0.0.1
VM
ip: 10.0.0.2
gw: 10.0.0.1
dnsmasq: static leases for

10.0.0.2 & 10.0.0.5
eth0
linux
bridge
eth0
nova-compute &
nova-network
nova-compute
& nova-network
switch
10.0.0.1(gw)
VlanManager
Features:
Can manage many IP subnets

Uses a dedicated network bridge for each network
Can map networks to tenants
Runs a DHCP server (dnsmasq) for instances to boot from
Separates network traffic with 802.1Q VLANs
eth1
eth1
VM_net2
VM_net1
VM_net1
VM_net2
br100
br200
dnsmasq_net1
eth0
nova-compute &
nova-network
dnsmasq_net2
eth0.100
nova-compute
& nova-network
eth0 eth0.200
VlanManager - switch requirements
The switch requires support for 802.1Q tagged VLANs to

connect instances on different compute nodes
eth1
eth1
VM_net1
VM_net2
VM_net2
VM_net1
br100
br200
br100
br200
eth0.100
nova-compute
& nova-network
eth0.200
eth0 eth0.200
nova-compute
& nova-network
tagged traffic
802.1Q capable switch
eth0
eth0.100
Network managers comparison

Name
Possible use cases
FlatManager
Deprecated - should not be used for

any deployments.
Limitations
FlatDHCPManager
Internal, relatively small corporate

clouds which do not require tenant
isolation.
VlanManager
Public clouds which require L2 traffic

isolation between tenants and use of
dedicated subnets.
Only Debian derivatives

supported.
Single IP network suffers from
scalability limitations.
Instances share the same linux

bridge regardless which tenant
they belong to.
Limited scalability because of one
huge IP subnet.
Requires 802.1Q capable switch.

Scalable only to 4096 VLANs
Inter-tenant traffic
Compute node's routing table
consulted to route traffic
between tenants' networks
(based on IPs of the linux
bridges)
public ip
eth1
VM_net1
VM_net2
routing
10.100.0.0 via br100
10.200.0.0 via br200

br100
10.100.0.1
eth0.100
nova-compute
& nova-network
br200
10.200.0.1
eth0 eth0.200
Accessing internet
eth1 address is set as the
compute node's default gateway

Compute node's routing table
consulted to route traffic from
the instance to the internet over
the public interface (eth1)
source NAT is performed to the
compute node's public address
public ip
eth1
VM_net1
VM_net2
routing/NAT
0.0.0.0 via eth1

src 10.100.0.0 -j SNAT to public_ip
br100
10.100.0.1
eth0.100
nova-compute
& nova-network
br200
10.200.0.1
eth0 eth0.200
Floating & fixed IPs

Fixed IPs:
given to each instance on boot (by dnsmasq)
private IP ranges (10.0.0.0, 192.168.0.0, etc.)
only for communication between instances and to
external networks
inaccessible from external networks
Floating IPs:
allocated & associated to instances by cloud users

bunches of publicly routable IPs registered in
Openstack by cloud dmin
accessible from external networks
multiple floating IP pools, leading to different ISP-s
Floating IPs
User associates a floating
IP with VM:
floating IP is added as a
secondary IP address on
compute node's eth1 (public
IF)
DNAT rule is set to redirect
floating IP -> fixed IP
(10.0.0.2)
floating IP
added as a
secondary IP
on eth1
vm_float_ ip: 92.93.94.95
public ip
eth1
floating IP DNAT:
-d 92.93.94.95/32 -j DNAT -to-destination 10.0.0.2
VM
10.0.0.2
VM
10.0.0.3
linux
bridge
eth0
nova-compute &
nova-network host
Limitations
Networking management is available only for
admin
Implementation is coupled with networking
abstractions
QUANTUM - a new networking platform

Provides a flexible API for service providers or their
tenants to manage OpenStack network topologies
Presents a logical API and a corresponding plug-in
architecture that separates the description of network
connectivity from its implementation
Offers an API that is extensible and evolves
independently of the compute API
Provides a platform for integrating advanced networking
solutions

solutions

solutions

solutions

E
C
I
Presents a logical API and a corresponding
plug-in
V
R
architecture that separates the description
of network
E
S
connectivity from its implementation.
N
O
I
T
Offers an API that isCextensible
and evolves
independently R
ofA
the compute API
T
S
B
Provides
A a platform for integrating advanced networking
solutions
N
A
Quantum Overview
quantum abstracts
quantum architecture
quantum Open vSwitch plugin
quantum L3 agents
QUANTUM - abstracts - tenant network layout

provider nets
external net
8.8.0.0/16
external net
172.24.0.0/16
NAT
NAT
router1
10.0.0.1
GW
router2
192.168.0.1
10.23.0.1
GW
vm
vm
vm
vm
10.0.0.2
192.168.0.2
10.23.0.2
10.23.0.3
local nets
QUANTUM - abstracts
virtual L2 networks (port & switches)

IP pools & DHCP
virtual routers & NAT
"local" & "external" networks
Quantum network abstracts vs hardware

compute node
vm
DC net
vm
compute node
vm
vm
vm
vm
remote
DC
tunnel
DC DMZ
compute node
(another DC)
internet
vm
vm
vm
QUANTUM - abstracts
virtual L2 networks
IP pools & DHCP
virtual ports & routers
"local" & "external" networks
virtual networks delivered on

top of datacenter hardware
Quantum - architecture
source: http://openvswitch.org
quantum uses plugins to deal

with hardware diversity and
different layers of the OSI model
Quantum plugin architecture
quantum plugin determines

network connectivity layout.
Folsom - available quantum plugins
Linux Bridge
OpenVSwitch
Nicira NVP
Cisco (UCS Blade + Nexus)
Ryu OpenFlow controller
NEC ProgrammableFlow Controller
Example plugin: OpenVswitch
Example - Open vSwitch plugin

leverages OpenVSwitch software switch
modes of operation:
FLAT:
networks share one L2 domain

VLAN:
networks are separated by 802.1Q VLANs
TUNNEL:
traffic is carried over GRE with different pernet tunnel IDs
Open vSwitch plugin - bridges
single integration
bridge "br-int"
compute node
vm
vm
LV_1
LV_2
br-int
a patch port leads to

a bridge which is
attached to a
physical interface
ovs
daemon
breth0
q-agt
eth0
Integration bridge & NIC bridge
Open vSwitch plugin - ovs daemon
compute node
openvswitch
daemon accepts
calls from Quantum
agent & reconfigures
network
Quantum agent
accepts calls from
the central quantum
server via plugin
vm
vm
LV_1
LV_2
br-int
ovs
daemon
breth0
quantum server
qplugi
n
q-agt
eth0
Open vSwitch plugin vs compute farm
quantum server
qplugi
n
Quantum server manages an OpenVswitch server farm

through Quantum agents on compute nodes
Open vSwitch plugin - local VLANs

traffic separated by
"local" VLANs:
LV_1, LV_2
compute node
vm
vm
LV_1
LV_2
br-int
ovs
daemon
breth0
q-agt
eth0
One bridge, many VLANs
OpenStack connectivity - Open vSwitch plugin

leverages OpenVSwitch software switch
modes of operation:
FLAT:
networks share one L2 domain

VLAN:
networks are separated by 802.1Q VLANs
TUNNEL:
traffic is carried over GRE with different pernet tunnel IDs
Open vSwitch plugin - FLAT mode
Single L2 bcast
domain
Local vs global traffic ID-s - FLAT mode
openvswitch
FLAT:
LV_1 >> UNTAGGED

LV_1
VM
br-int
br-eth0
eth0
Local VLAN tag stripped before sending down the wire
Open vSwitch plugin - VLAN mode
802.1Q VLANs
Local vs global traffic ID-s - VLAN mode
openvswitch
VLAN:
LV_1 >> NET1_GLOBAL_VID

LV_1
VM
br-int
br-eth0
eth0
Local VLAN tag changed to "global" VLAN tag.
Open vSwitch plugin - Tunnel mode
GRE tunnel IDs
Local vs global traffic ID-s - Tunnel mode
openvswitch
GRE:
LV_1 >> NET1_TUNNEL_ID

LV_1
VM
br-int
br-tun
Local VLAN tag changed to GRE tunnel ID
eth0
VLAN vs GRE scalability
VLAN ID: 12bit field:
2^12 = 4096
GRE tunnel ID: 32bit field: 2^32 = 4
294 967 296
Tenant connection needs - provider networks

compute node
vm
vm
compute node
vm
DC net
need for many physical

connections per
compute node
vm
vm
vm
remote
DC
tunnel
DC DMZ
compute node
(another DC)
internet
vm
vm
vm
Integration with cloud and datacenter networks
dedicated per-NIC
bridge
Integration with cloud and datacenter networks

vlan range:
100-400
vlan range:
401-800
tunnel ID
range:
50-600
vlan ranges are

mapped to per-NIC
bridges
Agents: routing/NAT & IPAM
Tenant connection needs - L3

vm
vm
vm
vm
vm
vm
vm
Ensuring "wired" instance

connectivity is not enough
vm
vm
10.1.0.0/24
vm
vm
10.0.0.0/24
vm
vm
vm
vm
10.2.0.0/24
vm
We need IP addresses
vm
vm
10.1.0.0/24
vm
vm
10.0.0.0/24
vm
vm
vm
vm
10.2.0.0/24
vm
We need routers
vm
vm
10.1.0.0/24
vm
vm
10.0.0.0/24
vm
vm
vm
vm
10.2.0.0/24
vm
We need external
access/NAT
vm
vm
Quantum vs L3 services
dhcp-agent &
quantum db
for IP address
mgmt
10.1.0.0/24
vm
vm
10.0.0.0/24
vm
vm
vm
vm
10.2.0.0/24
vm
vm
l3-agent for
routing & NAT
vm
IPAM
create Quantum network

create Quantum subnet
pair subnet with network
boot instances and throw them into the network
DHCP
dhcp-agent: aims to manage different dhcp backends to
provide dhcp services to openstack instances.
Routing
l3-agent:
creates virtual routers and plugs them into different

subnets
provides connectivity between Quantum networks

creates default gateways for instances
NAT
l3-agent: creates NAT-ed connections to "external" networks
Compute cluster /w plugins & agents
quantum server
dhcp host
gateway host
dnsmasq
routing/NAT
dhcp-agent
l3-agent
Quantum - plugin & agent summary

OVS
flat
vlan
CISCO
gre
nexus
UCS
NICIRA
RYU
NEC
OTHER?
NVP
Open
Flow/O
VS
Progra
mmabl
eFlow
???
QUANTUM
dnsma
sq
DHCP
AGENT
NAT
router
L3
AGENT
iptable
s
???
FIREWALL
AGENT
HApro
xy
F5
L-B
AGENT
???
Quantum /w OVS - model summary

each tenant manages his IP addresses independently
networks separated on L2 with VLANs or GRE
tunnel IDs
disjoint concepts of "network" and "IP pool"
tenant networks connected with one another by
"virtual routers"
internal vs external networks
Quantum vs nova-network
NOVA-NETWORK
QUANTUM
multi-host
Yes
No
VLAN networking
Yes
Yes
Flat(DHCP)
networking
Yes
Yes
Tunneling (GRE)
No
Yes
many bridges
No
Yes
SDN
No
Yes
IPAM
Yes
Yes
dashboard support
No
Limited - no floating
IPs
Yes
Limited - only with

non-overlapping IP
pools
security groups
Questions?
kishanov@mirantis.com

Openstack Super Bootcamp PDF

Uploaded by

Copyright:

Available Formats

Openstack Super Bootcamp PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Openstack Super Bootcamp PDF

Uploaded by

Copyright:

Available Formats

What are the main components of OpenStack Nova?

What are the main components of OpenStack Nova?

How does Quantum networking differ from Nova networking?

How does Quantum networking differ from Nova networking?

OpenStack

nova: Cloud Controller

Step 1: Request VM Provisioning via UI/CLI

nova: Cloud Controller

Step 2: Validate Auth Data

nova: Cloud Controller

Step 2: Validate Auth Data

nova: Cloud Controller

Step 3: Send API request to nova-api

nova: Cloud Controller

Step 4: Validate API Token

nova: Cloud Controller

Step 4: Validate API Token

nova: Cloud Controller

Step 5: Process API request

nova-api parses request and

nova: Cloud Controller

Step 6: Publish provisioning request to queue

nova-api makes rpc.call to

nova: Cloud Controller

Step 6: Pick up provisioning request

nova: Cloud Controller

Step 7: Schedule provisioning

Scheduler fetches information

nova: Cloud Controller

Step 8: Start VM provisioning on compute node

Scheduler publishes message

nova: Cloud Controller

Step 9: Start VM rendering via hypervisor

nova: Cloud Controller

Step 10: Request VM Image from Glance

nova: Cloud Controller

Step 11: Get Image URI from Glance

nova: Cloud Controller

Step 12: Download image from Swift

hypervisor downloads image

nova: Cloud Controller

Step 13: Configure network

nova: Cloud Controller

Step 14: allocate and associate network

nova: Cloud Controller

Step 15: Request volume attachment

nova: Cloud Controller

nova: Cloud Controller

Still part of nova

nova: Cloud Controller

API for networking and block storage are still

UI: horizon or CLI

UI: horizon or CLI

Essex' networking model overview

single-host vs multi-host networking

Revisit of KVM networking with linux bridge

KVM host == nova-compute

What happens if nova-network host dies

Multi-host networking - features