Netzwerkkonfiguration

[phish108]

• [x] Ziel: OpenVSwitch, um die beiden Knoten zu verbinden und die VMs von aussen zugänglich zu machen.

https://ubuntu.com/server/docs/virtualization-libvirt

https://netplan.io/reference/#introduction

https://netplan.io/examples/?_ga=2.53387757.474432096.1612777438-2037267900.1574710488

https://askubuntu.com/questions/1278670/ovsintport-with-netplan

• [x] Das netzwerk interface muss ovs tauglich markiert werden. Stichwort templates.

https://ubuntu.com/blog/the-new-simplicity-to-consume-dpdk

http://lost-and-found-narihiro.blogspot.com/2017/08/ubuntu-uvtool-how-to-use-template-and.html

[phish108]

Knoten vorbereiten

System Komponenten

es müssen die folgenden Packete installiert sein:

• openvswitch-switch-dpdk

Installation

OpenvSwitch (OVS) erlaubt die Abstraktion von Netzwerkkonzepten für virtualisierte Umgebungen. Für unsere Zwecke verwenden wir OVS als Schnittstelle zum regulären Netzwerk sowie als Transportschicht für die Kommunikation zwischen den Virtualisierungsknoten.

Nach der Installation der Packete muss OVS mit ovs-vscfg init initialisiert werden.

Anschliessend muss eine Switch-Bridge eingerichtet werden:

ovs-vsctl add-br ovs0

Das ist die Komponente, die das physikalische Netzwerk mit den virtuellen Maschinen verbinden soll. Damit der Virtualisierungsknoten auch weiterhin erreichbar bleibt, muss eine interne Netzwerkschnittstelle erstellt werden, die dem Virtualisierungsknoten zugeordnet ist.

ovs-vsctl add-port ovs0 mgnt0 -- set interface mgnt0 type=internal

Damit diese Schnittstelle späte automatisch eine IP-Adresse erhält, muss die Datei /etc/netplan/00-installer-config.yaml angepasst werden. Der Inhalt sollte wie folgt aussehen:

# This is the network config written by 'subiquity'
network:
  ethernets:
    eno1:
      dhcp4: no
    mgnt0:
      dhcp4: true
      macaddress: xx:xx:xx:xx:xx:xx
  version: 2

Die MAC-Adresse müssen wir explizit aus unserem Devicepool wählen, damit der Knoten über einen festen Namen und IP angesprochen werden kann. Das ist notwendig, weil das mgnt0-Device bei jedem Boot-Vorgang eine neue (zufällige) MAC-Adresse erhalten würde. Wir hätten dann keine Chance den Server im Netz zu finden.

Danach "stecken" wir das Netzwerk um. Wir müssen berücksichtigen, dass wir im nächsten Schritt die Netzwerkverbindung verlieren werden und booten den Host neu.

ovs-vsctl add-port ovs0 eno1 ; reboot

Der Rebootprozess dauert etwa 1-2 Minuten. Danach müssen wir die neue Host IP herausfinden und uns neu mit dem Host verbinden.

Nach dem Login können wir die Konfiguration mit ovs-vsctl show überprüfen.

[phish108]

VMs in ein OVS-Netzwerk einbinden

Laut Mastering KVM - second edition muss die alte Kernel Bridge entfernt werden. Bei mir hat das aber nicht gestört und auch keine anderen Vor- oder Nachteile gebracht. Allerdings hat der naive Befehl: uvt-kvm create --bridge ovs0 test2 release=groovy nicht funktioniert. Nach ewig langem Probieren hat mich dieser Blog dann auf die richtige Fährte gebracht. Meine Lösung ähnelt dieser Strategie, wobei die ganze Netzwerkerei am Anfang bei uns nicht notwendig ist, sondern wie unter "Knoten vorbereiten" beschrieben durchgeführt werden kann.

Man muss für uvt-kvm das Netzwerk explizit auf Open vSwitch optimieren, damit die VM richtig erstellt wird. Dazu muss ein VM Template erstellt werden, wie es in diesem offiziellen Beitrag von Ubuntu steht. Ich habe die Templates (1 und 2) aus diesem Beitrag als Ausgangsbasis genommen und vereinfacht. Dieses Template muss zwingend die folgenden Elemente enthalten:

<domain type="kvm">
        <os>
                <type>hvm</type>
                <boot dev='hd'/>
        </os>
        <devices>
                <interface type="bridge">
                        <source bridge="ovs0"/>
                        <virtualport type='openvswitch'/>
                        <model type='virtio'/>
                        <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/>
                </interface>
                <serial type='pty'>
                        <source path='/dev/pts/3'/>
                        <target port='0'/>
                </serial>
        </devices>
</domain>

Dieses Template ist minimal, so dass wir die restlichen Parameter (CPU, Speicher usw.) frei spezifizieren können. Wichtig ist allerdings, dass das serial-Device vorhanden ist, denn sonst kommt man nicht auf die Konsole mit virsh console $HOSTNAME (und kann die IP-Adresse des Hosts nicht leicht herausfinden).

Mit diesem template funktioniert jedoch nicht mehr die Adressextration mit virsh domifaddr $HOSTNAME, weil nicht der DHCP von libvirt verwendet wird.

Das Template habe ich in die Datei vm_template.xml neben meiner cloud_init.cfg (aus #3) gespeichert. Anschliessend konnte ich die VM mit uvt-kvm wie folgt starten.

uvt-kvm create --template vm_template.xml \
               --user-data cloud_init.cfg \
               --cpu 2 \
               --memory 2048  \
              $HOSTNAME release=groovy

In der OVS-Bridge sehen wir nun auch die entsprechende(n) Schnittstelle(n). In folgenden Beispiel laufen 2 virtuelle Maschinen (mit vnet0 und vnet1).

# ovs-vsctl show
5bbca7ca-5604-400f-bbed-f710f468c7a6
    Bridge ovs0
        Port virbr0-nic
            Interface virbr0-nic
        Port ovs0
            Interface ovs0
                type: internal
        Port vnet1
            Interface vnet1
        Port vnet0
            Interface vnet0
        Port eno1
            Interface eno1
        Port mgnt0
            Interface mgnt0
                type: internal
    ovs_version: "2.13.1"

Wir müssen für jedes OVS-Netzwerk einen Netzwerkadapter mit der richtigen OVS-Bridge im Template spezifizieren.

[phish108]

Bridged Network für LXC Container

Mit LXC Containern kann eine OVS Bridge direkt verwendet werden.

Dazu muss die LXD Runtime darüber informiert werden, dass ein bridged-Netzwerk verwendet wird. Als Parameter wird dann das Bridge Gerät übergeben. Das ist in unserem Fall ovs0. Diese Konfiguration wird im Container Profil hinterlegt und für alle LXC Container im gleichen Profil übernommen.

Das Netzwerk muss mit lxc profile edit default angepasst werden.

Die eth0 Konfiguration muss so aussehen:

devices:
  eth0:
    name: eth0
    parent: ovs0
    nictype: bridged
    type: nic

Via cloud-init übergeben wir dann dem Container die restlichen Informationen für die Netzwerkkonfiguration. Hier müssen wir für die offiziellen VMs die jeweilige MAC-Adresse angeben.