Skip to content
Tim Ohliger edited this page Jul 4, 2017 · 4 revisions

Configuration

This page explains the configuration file migfra.conf. First each part is described and at last a full example is given.

communicator

Currently, only the type: mqtt is available. For identification in the MQTT network, a unique id has to be passed. Here, the placeholder <hostname> may be used, which is replaced with the hostname on which the migration-framework runs. subscribe-topic and publish-topic define the topics on which the migration-framework receives and sends messages. Here, the placeholder <hostname> may be used as well. The host must specify a hostname on which the mosquitto daemon runs. port defines the port on which the mosquitto daemon listens. The keepalive argument is defined by the mosquitto library as the following:

the number of seconds after which the broker should send a PING message to the client if no other messages have been exchanged in that time. A value of 60 seems reasonable.

communicator:
  type: mqtt
  id: fast-migfra-<hostname>
  subscribe-topic: fast/migfra/<hostname>/task
  publish-topic: fast/migfra/<hostname>/result
  host: devon
  port: 1883
  keepalive: 60

hypervisor

The hyervisor can be of type libvirt or dummy. If the type is libvirt an array of nodes may be passed optionally to define a set of nodes which should be checked for already running domains with the same name before starting a new domain. Also the driver and the transport protocol to be used for migration may be stated. Both are used to generate libvirt connection URIs which are described here. However, driver and transport may also be stated in tasks, which has precedence over configuration. The start-timeout and stop-timeout define how long the hypervisor waits for successful bootup or shutdown (in seconds).

hypervisor:
  type: libvirt
  nodes: [pandora1, pandora2]
  driver: qemu
  transport: tcp
  start-timeout: 60
  stop-timeout: 60

If the type is dummy one has to define the never-throw argument. This takes a boolean to specify if the dummy hypervisor should always succeed (true) or always throw an exception (false).

hypervisor:
  type: dummy
  never-throw: true

pscom-handler

The pscom-handler is optional and may be used to alter the topics or the QoS of the pscom-handler. Also, every sub-argument is optional, thus one may define specific topics but can omit the qos in order to use the default value. The request-topic and response-topic may contain the placeholder <vm_name> which is replaced by the name of the domain (may be changed or extended to name in the future since container are no virtual machines). qos may take 0, 1, or 2. The mqtt man page states:

Higher levels of QoS are more reliable, but involve higher latency and have higher bandwidth requirements.

0: The broker/client will deliver the message once, with no confirmation.

1: The broker/client will deliver the message at least once, with confirmation required.

2: The broker/client will deliver the message exactly once by using a four step handshake.

This example contains the default values:

pscom-handler:
  request-topic: fast/pscom/<vm_name>/any_proc/request
  response-topic: fast/pscom/<vm_name>/+/response
  qos: 0

Example

Here is a full example of the migfra.conf:

---
communicator:
  type: mqtt
  id: fast-migfra-<hostname>
  subscribe-topic: fast/migfra/<hostname>/task
  publish-topic: fast/migfra/<hostname>/result
  host: devon
  port: 1883
  keepalive: 60
hypervisor:
  type: libvirt
  nodes: [pandora1, pandora2]
pscom-handler:
  request-topic: fast/pscom/<vm_name>/any_proc/request
  response-topic: fast/pscom/<vm_name>/+/response
  qos: 0
...
Clone this wiki locally