Kategorie: Virtuelles

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…

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…

KVM-Netzwerk 1

Für einfache Tests reicht dies:
Skript qemu-ifup erstellen:
#!/bin/bash
tap=$1
echo "bring up $tap"
sudo ip link set $tap up
echo "add $tap to br0"
sudo brctl addif br0 $tap

und dieses Skript auch noch als qemu-ifdown erstellen:
#!/bin/bash
tap=$1
echo "remove $tap from br0"
sudo brctl delif br0 $tap
echo "shut down $tap"
sudo ip link set $tap down

Dieses Skript wird genutzt, um die virtuellen interfaces der Bridge hinzuzufügen, um darüber im Netz erreichbar zu sein.
Mit
qemu-kvm -hda /path/to/vm.img -net nic -net tap,script=/path/to/qemu-ifup,downscript=/path/to/qemu-ifdown
Und schon hat man die VM im gleichen Netz…

KVM Basiswissen

Weil ich es in der nächsten Zeit wohl öfter brauche…
Installation:
apt-get install libvirt-bin qemu-kvm virtinst
Sicherheitshalber hier gucken

Auf einer separaten Maschine evtl.
apt-get install virt-viewer virt-manager libvirtd-bin virtinst
ausführen, um den (entfernen) Host grafisch zu managen…

In der GUI kann jeder ne VM anlegen, wichtig ist ein ISO-File mit den Installationsdaten.
Ohne GUI ne VM erstellen, geht so:
Image-File erstellen
qemu-img create -f qcow2 OSNAME.img 10G
Installation „in“ die Datei starten…
kvm -m 512 -boot once=d -CDROM /PFAD/ISO-FILE TEST.img
Jetzt wird ne VNC-Verbindung geöffent, die man mit dem VNC-Viewer abgreifen kann.
Vorhandene Images können mit
virt-clone --original ORIGINALNAME --name NEUERNAME --file NEUEDATEI.img
geklont werden.
Starten lassen sich die Images einfach mit
kvm -m 512 TEST.img