Comment 8 for bug 1287194

Revision history for this message
Nathan Kinder (nkinder) wrote :

I added some additional content to the "Recommended Actions" section. The additional content covers configuring the list address for the epehmeral migration ports, the ability to tunnel migration traffic over the remote access port, and details about securing the live block migration traffic.

I believe this gives a more complete picture of how live migration can/should be secured. It also will allow this single OSSN to cover the issues described in bug 1240554 instead of having two separte (but similar) OSSNs.

The new/reworked sections are below. Feedback would be appreciated.

----------------------------------------------------------------------
In addition to requiring authentication for remote access to the libvirt daemon
on your OpenStack Compute nodes, it is also recommended to restrict network
access such that connectivity is only allowed between the Compute nodes.

The first thing that should be done is to restrict the network interfaces that
the libvirt daemon listens on for remote connections. By default, the libvirt
daemon listens on all interfaces when remote access is enabled. This can be
restricted by setting the following configuration directive in
/etc/libvirt/libvirtd.conf:

---- begin example libvirtd.conf snippet ----
listen_addr = <IP address or hostname>
---- end example libvirtd.conf snippet ----

Migration in the libvirt daemon also uses a range of ephemeral ports by
default. The connections to these ephemeral ports are not authenticated or
encrypted. It is possible to tunnel the migration traffic over the regular
libvirt daemon remote access port, which will use the authentication and
encryption settings that you have defined for that port. It is recommended
that you do this for the additional security that it provides. To enable
tunneling of the migration traffic, you must tell your OpenStack Compute
nodes to set the VIR_MIGRATE_TUNNELLED flag for live migration. This is done
by setting the following directive in /etc/nova/nova.conf:

---- begin example nova.conf snippet ----
live_migration_flag=VIR_MIGRATE_UNDEFINE_SOURCE, VIR_MIGRATE_PEER2PEER, VIR_MIGRATE_TUNNELLED
---- end example nova.conf snippet ----

The tunneling of migration traffic described above does not apply to live block
migration. Live block migration is currently only possible over ephemeral
ports.

If you choose to use the ephemeral migration ports, there are a few things that
you should be aware of. Unfortunately, there is no way to restrict the network
interfaces that these ephemeral ports will listen on in libvirt versions prior
to 1.1.4. If you are running version 1.1.4 or later of the libvirt daemon, you
can set the following directive in /etc/libvirt/qemu.conf to specify what
interfaces are used for the ephemeral migration ports:

---- begin example qemu.conf snippet ----
migration_address = <IP address>
---- end example qemu.conf snippet ----

It is also recommended to configure the firewall on each OpenStack Compute node
to only allow other Compute nodes to access the ports that are used for remote
access to the libvirt daemon. By default, this is port 16514 for TLS and 16509
for unencrypted TCP.

Additionally, migration over ephemeral ports uses a port range of 49152-49215.
You will need to allow your OpenStack Compute nodes to communicate with each
other over these ports if you choose not to tunnel the migration traffic over
the libvirt daemon remote access port.

You can check what ports you have configured for the libvirt daemon by looking
at the following configuration directives:

  tls_port (libvirtd.conf)
  tcp_port (libvirtd.conf)
  migration_port_min (qemu.conf)
  migration_port_max (qemu.conf)

If you are running a version of the libvirt daemon older than 1.1.4 and you
want to perform live block migration, you will need to allow your OpenStack
Compute nodes to communicate over port range 5900-49151. If you are running
version 1.1.4 or later of the libvirt daemon, the regular ephemeral migration
port range is used for live block migration.

Please consult the documentation for your firewall software for instructions on
configuring the appropriate firewall rules.