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…

KVM-Networking 2 (mit mehreren NICs)

Wenn ich jetzt nicht alle VMs mit in meine eine Bridge packen will, muss man etwas anderes machen.
Für jede VM erstelle ich mir erstmal ne eigenen Bridge
brctl addbr br[2-x]
ip addr set dev brX 10.0.X.1
ip link set dev brX up

In der XML-Datei für die VM trage ich dann sowas ein

Wenn ich jetzt noch nen DHCP-Server für die Interfaces aufsetze (z.B. dhcpd von isc) und dort sowas eintrage
subnet 10.0.X.0 netmask 255.255.255.0 {
option routers 10.0.X.1;
range 10.0.X.10 10.0.X.200;
}

und in der
/etc/default/isc-dhcp-server
die Bridges eintrage, spielt der DHCP auch nicht im LAN verrückt, sondern versorgt nur die einzelnen VMs mit IPs.

Damit die Kommunikation nach draussen klappt, muss noch eine Route auf dem Host gesetzt werden, der das (hier genutzte) 10er Netz routet…