OpenVSwitch und VirtualBox

Für meine Tests spiele ich viel mit Virtualbox rum. Um noch etwas flexibler zu sein, habe ich jetzt auf meinem Linux-Notebook OpenVSwitch (OVS) installiert und so konfiguriert, dass VirtualBox (VB) sich mit den Bridges verbinden kann.

sudo ip tuntap add mode tap vnet0
sudo ip link set vnet0 up
sudo ovs-vsctl add-br vbox
sudo ovs-vsctl add-port vbox vnet0
sudo ip link set vbox up

In VB verbinde ich die VM nun einfach mit vnet0.
vnet0 ist irgendwas mit ethX in der VM (zum. bei einer Linux-VM) und erhält dort von mir per
ip addr add 10.0.0.1/24 dev eth0
eine IP.

Auf meinem Notebook mache ich das gleiche, nur mit vbox und ner anderen IP.
An diese OVS-Bridge kann ich nun beliebig viele VMs dranhängen, die alle miteinander kommunizieren können. Die VMs benötigen nur eine vNIC, die am vSwitch angeschlossen ist…

Advertisements

OpenVSwitch virtelle Testumgebung

Um schön mit OVS spielen zu können und alle Features losgelöst von irgendwelchen VMs, Hypervisoren und Konsorten zu testen, helfen die Network Namespaces von iproute2 weiter.
Ein einfaches Szenario zum Testen
host1 OVS host2
lässt sich so realisieren:

ip netns add ns1
ip netns add ns2
ovs-vsctl add-br BRIDGE
ip link add tap1 type veth peer name ovs-tap1
ovs-vsctl add-port BRIDGE ovs-tap1
ip link set tap1 netns ns1
ip netns exec ns1 ip link set dev tap1 up
ip link set dev ovs-tap1 up

ip link add tap2 type veth peer name ovs-tap2
ovs-vsctl add-port BRIDGE ovs-tap2
ip link set tap2 netns ns2
ip netns exec ns2 ip link set dev tap2 up
ip link set dev ovs-tap2 up

per

ip netns exec ns1 bash

wird in den Namespace ns1 gewechselt und es kann nun hin- und her gepingt werden.
Nimmt man ein ovs-tap* aus dem Switch raus, ist die Verbindung weg und nüscht geht mehr…

OpenStack Berechtigungen

Mich hat es Nerven gekostet:
keystone role-list
keystone user-list
keystone tenant-list

Ein User (meist in der entsprechenden conf-Datei hinterlegt) muss auch als keystone user (also in der user-Tabelle in der Keystone-DB) eingetragen sein.
Desweiteren muss es einen Tenant (Container, Mieter,Projekt,???) geben, der Berechtigungen umschreibt (Vllt. sollte ich nochmal lesen, was das Dingen wirklich macht)
Und es muss noch dazu die passende Rolle geben…
am Ende macht ein
keystone user-role-add --user=USERNAME_AUS_CONF --role=ADMIN_ROLLEN_ID --tenant_id=SERVICE_ID
die Möglichkeit, dass ein Service / User sich mit Keystone verbindet…
Normalerweise sollte es daher reichen:
in der conf-Datei:
admin_tenant_id=admin
admin_user=nova
(Oder nen anderen Servicenamen)
Und dann
keystone user-role-add --user nova --role=admin --tenant service

OpenStack Installationsprobleme unter Debian

Die haben sich ja viel Mühe mit der Installationsanleitung für OpenStack unter Debian 7 gegeben. Aber irgendwie tut es bei mir doch nicht alles, was es tun sollte…
Scheinbar klappt die Initialisierung der DB mit den korrekten User und Tenant-Einstellungen automatisiert über dbconfig nicht richtig (bei mir jedenfalls nicht.)
Am Ende sind keine User in der keystonedb-Tabelle user eingetragen, das mus man dann doch wieder händisch machen…
Am besten erstmal in der /etc/keystone/keystone.conf ein eigenes Admin-Token hinterlegen (Sch* auf Sicherheit, ich nehm mal 123)
Dann den Dienst neustarten.
Dann etwa so:
export OS_SERVICE_TOKEN=123
export OS_SERVICE_ENDPOINT=http://controller:35357/v2.0

und dann in etwa so:
keystone tenant-create --name=admin --description="Admin Tenant"
keystone tenant-create --name=service --description="Service Tenant"
keystone user-create --name=admin --pass=ADMIN_PASS --email=root@localhost
keystone role-create --name=admin
keystone user-role-add --user=admin --tenant=admin --role=admin

Und schon klappt es…