There are multiple ways to easily deploy Skydive, in this section we are going to explain the most common ways.

Downloading binary

The easiest way is to download a static binary of Skydive. There are two kind of binaries, one is built each time a feature or a bug fix is available (continuous binary) , the others are provided for each release .

Since Skydive uses the same binary for all its component, one can use it as agent, analyzer or client.

All-in-One mode

This mode start an analyzer and an agent at once.

$ skydive allinone [--conf etc/skydive.yml]

Agent and Analyzer separately

skydive agent [--conf etc/skydive.yml]
skydive analyzer [--conf etc/skydive.yml]


skydive client

Vagrant deployment

You can use Vagrant to deploy a Skydive environment with one virtual machine running both Skydive analyzer and Elasticsearch, and two virtual machines with the Skydive agent. This Vagrantfile, hosted in contrib/vagrant of the Git repository, makes use of the libvirt Vagrant provider] and uses Fedora as the box image.

cd contrib/vagrant
vagrant up


A Docker image is available on the Skydive Docker Hub account .

To start the analyzer :

docker run -p 8082:8082 skydive/skydive analyzer

To start the agent :

docker run --privileged --pid=host --net=host -p 8081:8081 \
  -e SKYDIVE_ANALYZERS=localhost:8082 \
  -v /var/run/docker.sock:/var/run/docker.sock skydive/skydive agent

Docker Compose

Docker Compose can also be used to automatically start an Elasticsearch container, a Skydive analyzer container and a Skydive agent container. The service definition is located in the contrib/docker folder of the Skydive sources.

docker-compose up


Skydive provides a DevStack plugin that can be used in order to have Skydive Agents/Analyzer set up with the proper probes by DevStack.

For a single node setup adding the following lines to your local.conf file should be enough.

enable_plugin skydive

enable_service skydive-agent skydive-analyzer

The plugin accepts the following parameters:

# Address on which skydive analyzer process listens for connections.
# Must be in ip:port format

# Configure the skydive analyzer with the etcd server address
# IP_ADDRESS:12379

# Inform the agent about the address on which analyzers are listening
# Must be in ip:port format

# ip:port address on which skydive agent listens for connections.

# The path for the generated skydive configuration file

# List of agent probes to be used by the agent
# Ex: netns netlink ovsdb

# Remote port for ovsdb server.

# Set the default log level, default: INFO

# List of public interfaces for the agents to register in fabric
#SKYDIVE_PUBLIC_INTERFACES="devstack1/eth0 devstack2/eth1"

The classical two nodes deployment

Inside the devstack folder of the Skydive sources there are two local.conf files that can be used in order to deployment two Devstack with Skydive. The first file will install a full Devstack with Skydive analyzer and agent. The second one will install a compute Devstack with only the skydive agent.

For Skydive to create a TOR object that links both Devstack, add the following line to your local.conf file :

SKYDIVE_PUBLIC_INTERFACES="devstack1/eth0 devstack2/eth1"

where devstack1 and devstack2 are the hostnames of the two nodes followed by their respective public interface.

Skydive will be set with the probes for OpenvSwitch and Neutron. It will be set to use Keystone as authentication mechanism, so the credentials will be the same than the admin.

Client & WebUI


Skydive client can be used to interact with Skydive Analyzer and Agents. Running it without any command will return all the commands available.

skydive client
  skydive client [command]

Available Commands:
  alert         Manage alerts
  capture       Manage captures
  inject-packet Inject packets
  pcap          Import flows from PCAP file
  query         Issue Gremlin queries
  shell         Shell Command Line Interface
  status        Show analyzer status
  topology      Request on topology [deprecated: use 'client query' instead]
  user-metadata Manage user metadata

      --analyzer string   analyzer address
  -h, --help              help for client
      --password string   password auth parameter
      --username string   username auth parameter

Global Flags:
  -c, --conf stringArray        location of Skydive configuration files, default try loading /etc/skydive/skydive.yml if exist
  -b, --config-backend string   configuration backend (defaults to file) (default "file")

Use "skydive client [command] --help" for more information about a command.

Specifying the subcommand will give the usage of the subcommand.

$ skydive client capture
Manage captures

  skydive client capture [command]

Available Commands:
  create      Create capture
  delete      Delete capture
  get         Display capture
  list        List captures

  -h, --help   help for capture

Global Flags:
      --analyzer string         analyzer address
  -c, --conf stringArray        location of Skydive configuration files, default try loading /etc/skydive/skydive.yml if exist
  -b, --config-backend string   configuration backend (defaults to file) (default "file")
      --password string         password auth parameter
      --username string         username auth parameter

Use "skydive client capture [command] --help" for more information about a command.

If an authentication mechanism is defined in the configuration file the username and password parameter have to be used for each command. Environment variables SKYDIVE_USERNAME and SKYDIVE_PASSWORD can be used as default value for the username/password command line parameters.

Skydive uses the Gremlin traversal language as a topology request language. Requests on the topology can be done as following :

$ skydive client query "G.V().Has('Name', 'br-int', 'Type' ,'ovsbridge')"
    "Host": "pc48.home",
    "ID": "1e4fc503-312c-4e4f-4bf5-26263ce82e0b",
    "Metadata": {
      "Name": "br-int",
      "Type": "ovsbridge",
      "UUID": "c80cf5a7-998b-49ca-b2b2-7a1d050facc8"

Refer to the Gremlin section for further explanations about the syntax and the functions available.


To access to the WebUI of agents or analyzer :


History and Datastore

Skydive can keep track of all the modifications of the topology and flows in a datastore. Skydive supports two backends: Elasticsearch and OrientDB.

In order to activate the history we need first to define the storage in the configuration file

Elasticsearch example:

    driver: elasticsearch

Then we need to use it as topology backend:

    backend: myelasticsearch

and as Flow backend

    backend: myelasticsearch


In order to use the Grafana datasource plugin we need to use a data store, please see the upper section.

A docker image with the datasource plugin available can be use as following:

docker run -d --name=grafana -p 3000:3000 skydive/skydive-grafana-datasource

For further information, please see the plugin README