Instalação do Intel Xeon Phi no CentOS 7

Este documento detalha a instalação dos pacotes de software necessários para o funcionamento do Intel Xeon Phi (MPSS 3.6.1) no CentOS Linux release 7.2.1511 (Core) com kernel 3.10.0-327.el7.x86_64. Importante observar que a versão do kernel deve ser compatível. Caso não esteja de acordo com a documentação do MPSS, deve-se instalar os pacotes do kernel adequado. Veja mais em: http://registrationcenter.intel.com/irc_nas/8495/mpss_users_guide.pdf

0. Desabilitar o NetworkManager

Por padrão, o NetworkManager vem habilitado no CentOS. Devemos desabilitá-lo :

# chkconfig NetworkManager off
# chkconfig network on
# service NetworkManager stop
# service network start

1. Download dos Pacotes

Baixar o arquivo mpss-3.6.1-linux.tar do site https://software.intel.com/en-us/articles/intel-manycore-platform-software-stack-mpss:

# mkdir /root/mic
# cd /root/mic
# wget http://registrationcenter.intel.com/irc_nas/8495/mpss-3.6.1-linux.tar
# tar xvf mpss-3.6.1-linux.tar

2. Instalar os pacotes

Primeiro passo desta fase, verificar que não existe uma versão anterior instalada:

# rpm -qa | grep -e intel-mic -e mpss

Esse comando não deve retornar nenhum valor. Em seguida, devemos instalar os pacotes base:

# cd /root/mic/mpss-3.6.1
# cp ./modules/`uname -r`.rpm
# yum install *.rpm

Caso encontre algum problema de incompabilidade no kernel, por exemplo não encontrar na pasta /root/mic/mpss-3.6.1/modules os pacotes equivalentes a sua versão, faça o seguinte:

# yum install kernel-headers kernel-devel
# cd /root/mic/mpss-3.6.1/src
# rpmbuild –rebuild mpss-modules.src.rpm
# yum install /root/rpmbuild/RPMS/x86_64/
.rpm

Os passos anteriores podem ser feitos a cada atualização do kernel. Mas talvez seja melhor não atualizar os pacotes do kernel.

Por último, carregue o módulo do kernel da mic:

# modprobe mic

Demora alguns segundos. Se nada retornar, então deu tudo certo. Vamos chegar o status da mic:

# micctrl -s
# mic0: ready

Devemos atualizar a memória flash do dispositivo:

# micflash -update -device all
No image path specified – Searching: /usr/share/mpss/flash
mic0: Flash image: /usr/share/mpss/flash/EXT_HP2_C0_0391-02.rom.smc
mic0: Flash update started
mic0: Flash update done
mic0: SMC update started
mic0: SMC update done
mic0: Transitioning to ready state
Please restart host for flash changes to take effect

3. Aplicar as configurações default

Inicializar as configurações default:

# micctrl –initdefaults

Verificar se o serviço mpss pode ser inicializado:

# service mpss start

Habilitar para inicializar junto com o sistema:

# chkconfig mpss on

Verificar se é possível entrar no mic através do SSH (você precisa ter criado a chave do root antes):

# ssh mic0

Executar dois comandos que verificam o status da mic:

# miccheck

# micinfo

4. Adicionar um usuário

Primeiro, adicione o usuário no host:

# adduser usuario

# passwd usuario

Em seguida logue como o usuário e crie uma chave SSH:

\$ ssh-keygen

De volta ao root, adicione o usuário ao mic:

# micctrl –useradd=usuario

Pronto! Agora o usuário pode logar no mic.

Anúncios

Uma pequena comparação entre o Generics do Java e do C#

Meu objetivo neste post é comparar uma característica do Generics do Java e do C# que encontrei quando tentei criar uma classe para representar uma matriz. Queria guardar a matriz em um vetor linear e acessar seus elementos fazendo uma pequena aritmética no número de linhas e colunas. O objetivo era parametrizar a classe para que pudesse criar matrizes para qualquer tipo numérico.

Comecei pelo Java e tentei o seguinte código:

package matrix;

public class Matrix <T extends Number> {

	private int rows;
	private int columns;
	private T[] linearArray;
	
	public int rows() { return rows;}
	public int columns() { return columns;}
	
	public Matrix  (int rows, int cols){
		this.rows = rows;
		this.columns = cols;
		linearArray = new T[rows*columns];
	}
	
	public T get(int i, int j) {
		if (i > rows || j > columns)
			return null;
		int localIndex = i * rows + j;
		return linearArray[localIndex];
	}
	
	public void set(int i, int j, T value) {
		if (i > rows || j > columns)
			return;
		int localIndex = i * rows + j;
		linearArray[localIndex] = value;
	}
}

O problema é que esta linha:

linearArray = new T[rows*columns];

Fornece o seguinte erro:

Cannot create a generic array of T	Matrix.java	/MatrixComponents/src/matrix	line 15	Java Problem

Pela descrição, é um problema do Java. Criei então código semelhante em C#:

using System;

namespace TestandoArraysGenerics
{
	public class Matrix <T>
	{
		T[] elements;
		int rows;
		int columns;

		int Rows {
			get {
				return rows;
			}
			set {
				rows = value;
			}
		}

		int Columns {
			get {
				return columns;
			}
			set {
				columns = value;
			}
		}

		public Matrix (int rows, int columns)
		{
			this.rows = rows;
			this.columns = columns;
			elements = new T[rows * columns];
		}

		public T this[int i, int j] {
			get {
				return elements[i * rows + j];
			}
			set {
				elements[i * rows + j] = value;
			}
		}
	}
}

A linha

elements = new T[rows * columns];

Funciona perfeitamente. Pergunto então, existe uma situação insegura que Java previne e C# permite? Ou é o contrário, C#, mais moderna e recente, decidiu implementar Generics até a raiz da linguagem?

Compilar MPICH2/MPI.NET Ubuntu

O MPI.NET é uma biblioteca que permite escrever aplicações MPI usando C#. É muito parecida com o MPI para C, mas tem algumas facilidades interessantes, principalmente se você deseja enviar objetivos através de primitivas de comunicação MPI. Nesse tutorial, vamos usar pacotes e código fonte que não fazem parte da instalação oficial do Ubuntu. Na verdade, sugiro que retire qualquer pacote mono ou mpich que tenha instalado no Ubuntu antes de começar. Eu testei na 12.04 LTS e na 14.04 LTS, os passos sãos os mesmos. Vamos instalar tudo no /opt.

1) Instalar o MONO

Seguir as instruções no site abaixo:
http://software.opensuse.org/download/package?project=home:tpokorra:mono&package=monodevelop-opt
Depois executar:
# ln -s /opt/mono/bin/ilasm /opt/mono/bin/ilasm2
# source /opt/mono/env.sh
# ln -s /opt/mono/env.sh /etc/profile.d/mono.sh

2) Instalar o MPICH

Na pasta do código fonte do MPI (usei o mpich2-1.3)
# mkdir /opt/mpich2-1.3
# ./configure –prefix=/opt/mpich2-1.3 –enable-shared –enable-lib-depend
# make
# make install
Colocar o seguinte em /etc/profile.d/mpich.sh:
export PATH=/opt/mpich2-1.3/bin:$PATH
export LD_LIBRARY_PATH=/opt/mpich2-1.3/lib:$LD_LIBRARY_PATH
export LD_RUN_PATH=/opt/mpich2-1.3/bin:$LD_RUN_PATH
export MANPATH=/opt/mpich2-1.3/share/man:$MANPATH
Depois:
# source /etc/profile.d/mpich.sh

3) Instalar o MPI.NET

Na pasta do código do fonte do MPI.NET
# mkdir /opt/mpi.net
# git clone https://github.com/jmp75/MPI.NET.git mpi.net
# cd mpi.net
# LOCAL_DIR=/opt/mpi.net
# sh autogen.sh
# ./configure –prefix=/opt/mpi.net
# make
# make install
# gacutil -i /opt/mpi.net/lib/MPI.dll
# gacutil -i /opt/mpi.net/lib/MPIUtils.dll

4) Compilar código de exemplo

Salve o conteúdo abaixo em um arquivo chamado Hello.cs.

using System;
using System.Collections.Generic;
using MPI;

class Hello{
    static void Main(string[] args){
		IDictionary<int, MPI.Intracommunicator> colors = new Dictionary<int, MPI.Intracommunicator>();

		MPI.Environment mpi = new MPI.Environment(ref args);
		MPI.Intracommunicator worldComm = Communicator.world;
		int min = 8; int max=min; int rank = min;

		rank = worldComm.Rank;
		min = worldComm.Allreduce<int>(rank+1, MPI.Operation<int>.Min);
		max = worldComm.Reduce<int>(rank+1, MPI.Operation<int>.Max, 1);

		colors[rank] = (MPI.Intracommunicator)worldComm.Split(rank+100, rank);

		int rec = 8;
		if (rank == 0) {
			MPI.Request req = worldComm.ImmediateSend<int> (50, rank, 0);
			rec = worldComm.Receive<int> (rank, 0);
			req.Wait();
		}
		Console.WriteLine("Node {0} of {1} - min={2} - max={3} - rec={4}\n", rank, worldComm.Size, min,  max, rec);
		mpi.Dispose();
   }
}

$ export LD_LIBRARY_PATH=/opt/mpi.net/lib
$ gmcs -r:/opt/mpi.net/lib/MPI.dll Hello.cs
$ mpirun -np 2 mono ./Hello.exe

Se executar sem mensagens de erro, então sua configuração está OK!!!

Gerenciando VMs no VirtualBox por Linha de Comando

Introdução

O VirtualBox é uma ferramenta de fácil utilização para criação de máquinas virtuais. O ambiente gráfico é bastante intuitivo, com poucos cliques o usuário é capaz de colocar uma máquina virtual para executar. Entretanto, algumas vezes é mais cômodo utilizar a linha de comando para gerenciar as máquinas virtuais, principalmente se você deseja criar scripts para automatizar suas tarefas.

Iniciar uma máquina virtual pelo terminal

Ao contrário de outras ferramentas que possuem um comando para cada ação, o VirtualBox tem um comando apenas que engloba todas as ações, o VBoxManage. Não adianta tentar memorizar todas as opções, apenas as principais são importantes. Uma maneira fácil de listar as máquinas virtuais disponíveis é com a opção list.

VBoxManage list vms
"AdmLinux2014" {e5d22843-42b3-40f1-b7cb-1013b31feb99}
"GParted" {23213647-b9bf-41cd-a696-d023527de672}
"pfSense" {c078a303-8283-43b9-8f82-19d7524681d6}

Com a comando VBoxManage list vms, conseguimos ver quais as máquinas virtuais disponíveis. Se e somente se a máquina virtual estiver com os Adicionais para Convidados (Guest Additions), você conseguirá tirar proveito total do VBoxManage. Para inicializar uma VM específica, sem subir a interface gráfica, o ideal é usar o comando VBoxHeadless. Ele é muito útil quando você está hospedando um servidor na VM e não precisa da interface gráfica. O comando completo seria:


VBoxHeadless --startvm AdmLinux2014 --vrde off

Com isso, a VM inicializa, mas sem nenhuma tela para interação. Como controlá-la?

Enviando comandos para uma VM

Claro que você pode configurar o SSH e o redirecionamento de portas para logar na VM e executar comandos. Mas novamente, não é uma boa opção para scripts. É possível enviar um comando através do próprio VirtualBox. Por exemplo, o comando abaixo executa ifconfig em uma máquina virtual chamada AdmLinux2014:


VBoxManage --nologo guestcontrol AdmLinux2014 execute --image \\ "/sbin/ifconfig" --username usuario --password senha --wait-stdout

É um comando muito útil para, caso você esteja atribuindo IP através de uma bridge em uma interface do hospedeiro, descobrir qual o endereço a máquina recebeu.

Conclusão

Com essas duas dicas, é fácil criar um script que inicialize um certo conjunto de VMs e execute comandos de configuração em cada uma. Agora é só usar a imaginação 😉

A simple script for probing status from SLURM cluster nodes.

A common problem that appears once in a while in our cluster at CENAPAD-UFC is that not all the processes are terminated on the nodes when the job is aborted. This is a wrong behavior, and we haven’t been able to fix it within SLURM. The solution I found is to constantly check the nodes to see if any of them has load average greater than the number of cores available. If an overloaded node is found, the administrator may log in and check of zombie processes.

If you have a SLURM cluster, the best way to monitor the nodes is installing Ganglia . But if by any chance you can’t install Ganglia, another solution is using pdsh and a little bit of scripting in Python. The only customization needed is changing the value of numberOfCoresPerNode according your cluster configuration. Also, partition must be the name of a partition with all the nodes you want to monitor.

#!/usr/bin/python
# coding=UTF-8
import os
from collections import OrderedDict

numberOfCoresPerNode = 12
partition = "superlong"

# Retrieve the list of available nodes
stream = os.popen("sinfo -p " + partition + " -t ALLOC,IDLE -o %N | tail -1")
nodeStr = stream.readline()

print "Available nodes are: " + nodeStr[:-1]

# Retrieve the load of each node
stream = os.popen("pdsh -w " + nodeStr[:-1] + " cat /proc/loadavg")
output = {}
for line in stream.readlines() :
key = line.split(":")[0]
value = line.split(":")[1].split(" ")[1]
output[key] = value

# Sort the output dictionary according the keys values
orderedOutput = OrderedDict(sorted(output.items(), key=lambda item: int(item[0][6:])))

# Print information about each node.
print "Node load: "
for key in orderedOutput.keys():
if float(orderedOutput[key]) > numberOfCoresPerNode + 4:
print "OVERLOAD>>>" + key + ":" + orderedOutput[key]
else:
print key + ":" + orderedOutput[key]

We consider that a node is overloaded if the load is greater that the number of cores plus 4. That can be changed at the last for loop.

Enviando e-mail na linha de comando do Linux pelo GMail.

Muitas vezes é interessante enviar um e-mail através no BASH no Linux, seja para enviar relatórios ou avisos para o administrador. Entretanto, instalar um servidor SMTP completo apenas para essa função não é o ideal. Por que não utilizar um serviço confiável já existente? Vamos a seguir explicar como utilizar o GMail para envio de mensagens no BASH. Sem muito esforço, é possível adaptar essa solução para outros serviços de e-mail. Essa solução foi testada no Ubuntu 12.04 LTS.

O aplicativo que vamos utilizar é o MSMTP. A instalação dos pacotes necessários pode ser feita com o comando abaixo:

:~$ sudo apt-get install msmtp openssl ca-certificates

Com os pacotes instalados, devemos criar um arquivo de configuração para o MSMTP. Coloque o conteúdo abaixo no arquivo ~/.msmtprc:

account default
host smtp.gmail.com
port 587
from SEUUSUARIO@gmail.com
tls on
tls_starttls on
tls_trust_file /etc/ssl/certs/ca-certificates.crt
auth on
user SEUUSUARIO@gmail.com
password SUASENHA
logfile ~/.msmtp

Como esse arquivo contém sua senha, o ideal é impedir que os outros usuários possam lê-lo. Execute o comando abaixo para restringir as permissões:

:~$ chmod u+rw,g-rw,o-r ~/.msmtprc

Agora vamos criar um arquivo de e-mail. O arquivo deve possuir os campos From:, To: e Subject: (remetente, destinatário e assunto). Lembre de casar as informações do e-mail com o que você colocou no arquivo ~/.msmtprc. Veja um exemplo, salvo no arquivo email.txt:

To: larrypage@gmail.com
From: SEUUSUARIO@gmail.com
Subject: Teste de envio de e-mail pelo BASH.

Olá Larry,

Isto é um teste.

[]'s

Agora basta executar o comando abaixo e pronto, um e-mail será enviado:

:~$ msmtp -t < email.txt

Configuração de Um Ambiente de Testes para o OpenStack – Parte 4 – Compute

Aviso: este tutorial não funciona. Ele foi baseado em um guia que está no site oficial do projeto OpenStack (veja a parte 1). Entretanto, nos próprios comentários da página do tutorial, vários usuários relatam que as máquinas virtuais criadas não conseguem capturar um IP do DHCP. A razão do problema está relacionada com o serviço Quantum, cuja utilização no OpenStack é recente. Caso você deseje ter uma visão geral de virtualização e OpenStack, aconselho a seguir o tutorial mesmo assim. Na hora de aprender, um erro pode valer mais do que mil acertos.

Introdução

Vamos agora para a parte final do tutorial, a máquina Compute. Se você observar na tabela no post parte 1, verá que o nó Compute não foi configurado com uma interface com a Rede Externa (Host NAT). A configuração está correta, porém sem conexão com a Internet, fica difícil instalar os pacotes necessários. E quais são os pacotes? Por mais estranho que possa parece, a máquina Compute, que é virtual, precisará do KVM. Ou seja, uma máquina virtual que hospedará máquinas virtuais. Não posso deixar de lembrar que esta configuração é apenas para testes, o desempenho apresentado não será bom.

Configuração do Ubuntu

Primeiro, vamos aos pacotes. Execute ‘sudo apt-get install ubuntu-cloud-keyring’. Crie o arquivo /etc/apt/sources.list.d/cloud-archive.list com apenas a seguinte linha:

deb http://ubuntu-cloud.archive.canonical.com/ubuntu precise-updates/folsom main 

Depois, atualize a distribuição com os comandos ‘sudo apt-get update && sudo apt-get upgrade’. Instale os pacotes com o comando abaixo:

openstack@compute:~$ sudo apt-get install ntp kvm libvirt-bin pm-utils nova-compute-kvm openvswitch-switch quantum-plugin-openvswitch-agent

Com isso todos os pacotes estarão instalado e podemos partir para a configuração individual de cada um. Mas antes vamos terminar que configurar o Ubuntu.

Configuração de Rede

Você deve deixar seu arquivo /etc/network/interfaces parecido com o exemplo abaixo:

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
# auto eth0
# iface eth0 inet static
#        address 192.168.122.4
#        netmask 255.255.255.0
#        network 192.168.122.0
#        broadcast 192.168.122.255
#        gateway 192.168.122.1
#        dns-nameservers 192.168.122.1

auto eth1
iface eth1 inet static
        address 192.168.0.4
        netmastk 255.255.255.0
        network 192.168.0.0
        broadcast 192.168.0.255
	### static routing ###
	post-up route add -net 192.168.0.0 netmask 255.255.255.0 dev eth1
	pre-down route del -net 192.168.0.0 netmask 255.255.255.0 dev eth1

auto eth2
iface eth2 inet static
        address 10.10.10.3
        netmastk 255.255.255.0
        network 10.10.10.0
        broadcast 10.10.10.255
	### static routing ###
	post-up route add -net 10.10.10.0 netmask 255.255.255.0 dev eth2
	pre-down route del -net 10.10.10.0 netmask 255.255.255.0 dev eth2

A configuração do eth0 é opcional, já que instalamos o pacote. Se você encontrar algum problema, pode deixar essa configuração fora de comentários. Atualize os seguintes campos no arquivo /etc/sysctl.conf:

net.ipv4.conf.all.rp_filter = 0
net.ipv4.conf.default.rp_filter = 0  

Agora, reinicie a rede com ‘openstack@compute:~$ sudo service networking restart’.

NTP

Coloque apenas a linha ‘server 192.168.0.2’ no arquivo /etc/ntp.conf e reinicie o serviço com ‘sudo service ntp restart’.

KVM

Vamos agora configurar o KVM. Edite o arquivo /etc/libvirt/qemu.conf e adicione o seguinte:

cgroup_device_acl = [
    "/dev/null", "/dev/full", "/dev/zero",
    "/dev/random", "/dev/urandom",
    "/dev/ptmx", "/dev/kvm", "/dev/kqemu",
    "/dev/rtc", "/dev/hpet", "/dev/net/tun"]

É necessário desabilitar a bridge padrão do KVM, para evitar conflitos na rede:

openstack@compute:~$ virsh net-destroy default
openstack@compute:~$ virsh net-undefine default

Temos que habilitar a migração “quente”, configurando as seguintes opções no arquivo /etc/libvirt/libvirtd.conf:

listen_tls = 0
listen_tcp = 1
auth_tcp = "none"

Em seguida, a variável libvirtd_opts deve ser alterada no arquivo /etc/init/libvirt-bin.conf:

env libvirtd_opts="-d -l" 

Temos que alterar a mesma variável no arquivo /etc/default/libvirt-bin para ficar com o mesmo valores. Para finalizar, reiniciamos o KVM/Libvirt:

openstack@compute:~$ sudo service libvirt-bin restart
libvirt-bin stop/waiting
libvirt-bin start/running, process 3110

Nova

Edite o arquivo /etc/nova/api-paste.ini:

admin_tenant_name = service
admin_user = nova
admin_password = openstack

Edite o arquivo /etc/nova/nova-compute.conf:

[DEFAULT]
libvirt_type=qemu
libvirt_ovs_bridge=br-int
libvirt_vif_type=ethernet
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
libvirt_use_virtio_for_bridges=True

O campo libvirt_type está como qemu porque compute é uma máguina virtual. Fosse uma máquina real, o valor deveria ser kvm. Perceba que os dois primeiros arquivos editados não trazem nenhuma indicação que esta instalação do nova faz parte de uma nuvem. No próximo arquivo iremos adicionar os endereços IPs dos outros serviços da nuvem. Edite o arquivo /etc/nova/nova.conf :

[DEFAULT]

# MySQL Connection #
sql_connection=mysql://nova:openstack@192.168.0.2/nova

# nova-scheduler #
rabbit_host=192.168.0.2
rabbit_password=openstack
scheduler_driver=nova.scheduler.simple.SimpleScheduler

# nova-api #
cc_host=192.168.0.2
auth_strategy=keystone
s3_host=192.168.0.2
ec2_host=192.168.0.2
nova_url=http://192.168.0.2:8774/v1.1/
ec2_url=http://192.168.0.2:8773/services/Cloud
keystone_ec2_url=http://192.168.0.2:5000/v2.0/ec2tokens
api_paste_config=/etc/nova/api-paste.ini
allow_admin_api=true
use_deprecated_auth=false
ec2_private_dns_show_ip=True
dmz_cidr=169.254.169.254/32
ec2_dmz_host=192.168.0.2
metadata_host=192.168.0.2
metadata_listen=0.0.0.0
enabled_apis=metadata

# Networking #
network_api_class=nova.network.quantumv2.api.API
quantum_url=http://192.168.0.2:9696
quantum_auth_strategy=keystone
quantum_admin_tenant_name=service
quantum_admin_username=quantum
quantum_admin_password=openstack
quantum_admin_auth_url=http://192.168.0.2:35357/v2.0
libvirt_vif_driver=nova.virt.libvirt.vif.LibvirtHybridOVSBridgeDriver
linuxnet_interface_driver=nova.network.linux_net.LinuxOVSInterfaceDriver
firewall_driver=nova.virt.libvirt.firewall.IptablesFirewallDriver

# Compute #
compute_driver=libvirt.LibvirtDriver
connection_type=libvirt

# Cinder #
volume_api_class=nova.volume.cinder.API

# Glance #
glance_api_servers=192.168.0.2:9292
image_service=nova.image.glance.GlanceImageService

# novnc #
novnc_enable=true
novncproxy_base_url=http://192.168.122.2:6080/vnc_auto.html
vncserver_proxyclient_address=192.168.0.4
vncserver_listen=0.0.0.0

# Misc #
logdir=/var/log/nova
state_path=/var/lib/nova
lock_path=/var/lock/nova
root_helper=sudo nova-rootwrap /etc/nova/rootwrap.conf
verbose=true

Quantum

Vamos configurar o Open vSwitch, que nos dará acesso às bridges virtuais, e o próprio Quantum.

Open vSwitch

No caso do Open vSwitch, precisamos iniciar o serviço e adicionar as bridges:

openstack@compute:~$ sudo service openvswitch-switch start
 * Inserting openvswitch module
 * /etc/openvswitch/conf.db does not exist
 * Creating empty database /etc/openvswitch/conf.db
 * Starting ovsdb-server
 * Configuring Open vSwitch system IDs
 * Starting ovs-vswitchd
 * Enabling gre with iptables
openstack@compute:~$ sudo ovs-vsctl add-br br-int

Quantum

Para o Quantum, temos que configurar os dois arquivos com os IPs do Controller.

Edite o arquivo /etc/quantum/quantum.conf:

core_plugin = quantum.plugins.openvswitch.ovs_quantum_plugin.OVSQuantumPluginV2
auth_strategy = keystone
fake_rabbit = False
rabbit_host = 192.168.0.2
rabbit_password = openstack

Edite o arquivo /etc/quantum/plugins/openvswitch/ovs_quantum_plugin.ini:

sql_connection = mysql://quantum:openstack@192.168.0.2:3306/quantum
tenant_network_type = gre
tunnel_id_ranges = 1:1000
integration_bridge = br-int
tunnel_bridge = br-tun
local_ip = 10.10.10.3
enable_tunneling = True

E vamos iniciar o serviço:

openstack@compute:~$ sudo service quantum-plugin-openvswitch-agent start
quantum-plugin-openvswitch-agent start/running, process 3510

Toques finais

Para finalizar alguns toques finais. Irá facilitar muito nossa vida sincronizar o conteúdo dos arquivos /etc/hosts em cada máquina. Lembre de comentar a linha que atribui o loopback (127.0.0.1) para o hostname da máquina. Os arquivos devem ter as seguintes linhas:

192.168.0.2	controller
192.168.0.3	network
192.168.0.4	compute