ZFS statt LVM? Kein Plan, ich les heut Nacht mal etwas darüber…
LXD statt KVM wegen Performance (mein altes Nextcloud mount.davfs2-Problem)? Man könnte schon viel neues machen, wenn man das alte nicht schon könnte…
ICh bin offen für Neues. Es muss halt genug Erfahrung im Netz vorhanden sein, dass man leicht nachschauen kann. ZFS ist large aber nicht unbedingt bekannt viel auf Linux eingesetzt zu werden, oder?
LXD nutzt @zefanja - weiß zu wenig, ob das Zielführend ist.
Meine Performanz in mount.davfs2 ist übrigens auch sehr bescheiden. Aber ich glaube das liegt an der Nextcloud, nicht an der Virtualisierung.
VG, Tobais
Hi. ZFS (Oracle) bzw btrfs (-> Linux) sind auf jeden Fall super coole Features.
Ich habe auf einem Proxmox-Testserver “zum Spielen” ein RAID10 mit ZFS eingerichtet (4 Platten direkt auf dem Board, also ohne Controller dazwischen). Danach eine VM gestartet und eine Platte abgezogen, um zu schauen was geschieht. Proxmox schickt sofort eine E-Mail raus, dass das RAID nicht mehr i.O. ist aber das viel bessere daran: Platte wieder angesteckt und nach ein paar Sekunden (!!!) eine weitere E-Mail erhalten, dass alles wieder synchronisiert ist. Das sog. “Resilvering” funktioniert da super gut. Ein normaler RAID Controller wäre jetzt erstmal mindestens ein paar Stunden wenn nicht sogar ganze Tage beschäftigt!
Im Parallelthread wurde ja bereits weitergehend über ZFS, RAID-Z diskutiert…
Was Nextcloud angeht: wieviel RAM habt ihr der VM gegönnt?
ich hab jetzt „einmal mit alles“ auf einem 18.04er mit netplan. D.h. wenn man neu installiert, wird netplan installiert. Wenn man updatet bleibt ifupdown installiert und netplan macht einfach nix.
Folgendes file funktioniert nur dann, wenn man auch „systemd-network“ am Laufen hat (ist der standard) und nicht den network-manager.
root@kvmhost:~# ip -br addr list
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP
eth1 UP
br-server UP 10.16.1.22/16 fe80::3c82:8dff:fe41:846c/64
br-dmz UP fe80::c24:c5ff:fe8b:e361/64
br-red UP fe80::b805:1aff:fe79:aebd/64
bond0 UP fe80::a410:eeff:fe1e:5def/64
vlan-dmz@bond0 UP
vlan-rot@bond0 UP
vlan-wlan@bond0 UP
vlan-server@bond0 UP
vlan-teacher@bond0 UP fe80::a410:eeff:fe1e:5def/64
vlan-rest@bond0 UP fe80::a410:eeff:fe1e:5def/64
virbr0 DOWN 192.168.122.1/24
virbr0-nic DOWN
vnet0 UNKNOWN fe80::fc54:ff:fe9f:b8af/64
Die virtuellen Brücken „virbr0“ (und vermutlich auch vnet0) kommen von KVM/libvirtd
Man bekommt außerdem meist eine (lokale?) IPv6-Adresse, z.B. br-red. Das gefällt mir nicht. Ich habe es bei br-red mit leeren link-local und addresses Feldern probiert. Es scheint doch zu funktionieren, wenn man leere „addresses“-Felder einfügt, allerdings reicht dann nicht ein „netplan apply“, sondern ein reboot ist nötig, weil die IF schon UP sind, wird das durch apply scheinbar nicht revidiert…
Dagegen bekommt vlan-rot@bond0 keine mehr, weil br-red definiert ist.
Weil ich „br-teacher“ noch nicht definiert habe, bekommt vlan-teacher@bond0 eine IPv6 Adresse.
Das „lo“ Interface hab ich weiterhin in /etc/network/interfaces definiert. evtl. ist es dort aber nicht mehr nötig.
Hi zusammen, netplan-konfig verstehe wer will.
Ich hab nochmal eine Konfiguration mit “alles”, und eingefügten leeren Adressen, teilweise klappt das beim Bootvorgang, teilweise nicht:
Daraufhin bootet mein Rechner in folgende Konfiguration:
root@kvmhost:~# ip -br addr list
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP
eth1 UP
br-wlan UP
br-server UP 10.16.1.22/16 fe80::3c82:8dff:fe41:846c/64
br-red UP
br-dmz UP
bond0 UP
vlan-server@bond0 UP fe80::a410:eeff:fe1e:5def/64
vlan-dmz@bond0 UP fe80::a410:eeff:fe1e:5def/64
vlan-rot@bond0 UP fe80::a410:eeff:fe1e:5def/64
vlan-teacher@bond0 UP
vlan-rest@bond0 UP
vlan-wlan@bond0 UP fe80::a410:eeff:fe1e:5def/64
virbr0 DOWN 192.168.122.1/24
virbr0-nic DOWN
vnet0 UNKNOWN fe80::fc54:ff:fe20:ea70/64
Man sieht, dass bond0 keine IPv6 mehr hat, aber vlan-rot@bond0 und andere immernoch.
MAcht man dann nach dem booten (und hochfahren der virtuellen Maschinen) nochmal “netplan apply”, dann sieht es so aus, wie ich mir das wünsche:
root@kvmhost:~# netplan apply
root@kvmhost:~# ip -br addr list
lo UNKNOWN 127.0.0.1/8 ::1/128
eth0 UP
eth1 UP
br-wlan UP
br-server UP 10.16.1.22/16 fe80::3c82:8dff:fe41:846c/64
br-red UP
br-dmz UP
bond0 UP
vlan-server@bond0 UP
vlan-dmz@bond0 UP
vlan-rot@bond0 UP
vlan-teacher@bond0 UP
vlan-rest@bond0 UP
vlan-wlan@bond0 UP
virbr0 DOWN 192.168.122.1/24
virbr0-nic DOWN
vnet0 UNKNOWN fe80::fc54:ff:fe20:ea70/64
wir scheinen nicht die einzigen zu sein. Bei mir das selbe: über nemo und davs://owncloud,… ist der Zugriff superschnell, der mount lahmt elendiglich. Liegt also wohl am davfs2 paket.
die Idee, dass der Virtualisierer “gewinnt”, der zuerst “vollständig”
dokumentiert ist, finde ich bestrickend und will gern mit meinen
Rückmeldungen dazu beitragen
Wer als nächster einen anderen will, kann den dann ja auch dokumentieren
Die Alternativen gehörten m. E. aber eher ins Wiki. In der Doku
wirken Entscheidungsanforderungen dieser Art vor allem auf Neulinge (und
Entscheidungsträger!) eher abschreckend.
zu a.) Das Video sollte entweder ausgetauscht werden oder die Anleitung
müsste sich auf Ubuntu Server, Version 16.04 beziehen. Die Installation
von Version 18.04 unterscheidet sich doch sehr. Die Optionen
virtual-machine-host und openssh-server gibt es nicht und es war für
mich nicht intuitiv, was ich stattdessen auswählen sollte. Also habe ich
nichts ausgewählt, was vielleicht zu wenig war. openssh-server war auch
so installiert.
Wie Holger geschrieben hat, könnte man wohl später relativ einfach ein
Upgrade von 16.04 auf 18.04 durchführen, ohne die Konfiguration zu
zerschießen. Damit hätte man ja bis April 2021 Zeit.
zu b.) solange ich die “mitgelieferte” yaml benutzt habe, hatte der Host
Netz. Wenn ich diese mit der aus der Anleitung - mit denselben
Bezeichnungen enp0s7 und enp3s0 für die NIC - ersetzt habe, nicht mehr.
Möglicherweise ist nur eine Kleinigkeit falsch gewesen …
Welche Variante des Ubuntu Servers hast du verwendet? Die klassische Version (mit dem herkömmlichen Installer) oder den Liver-Server (mit dem neuen Installer Subiquity)?
Ja und Nein, die Entwicklung der Dokumentation findet halt öffentlich statt und es ist mir egal, ob das jemanden dann stört. Hinter verschlossenen Türen zu dokumentieren und dann zu präsentieren: „so, fertig“ hat sicher seinen Charme, aber dadurch ist die Doku nicht zwangsläufig besser.
Momentan seh ich das so, dass sowieso noch keiner den Startschuss zu einer beta-Version gegeben hat, wenn ich das richtig sehe. Und die Doku sollte rudimentär dafür geeignet sein.
Ne, 1. machen wir gleich 18.04 ohne update.
2. war meine Frage: ist das Medium „Video“ das geeignete. Ich habe eine kritische Stimme gehört, aber noch keine anderen. Sprich, ich kann das Video einfach rausnehmen und durch screenshots an den wichtigen STellen ersetzen. So war das bisher auch bevor morpweb mit den Videos kam.
Hm, ja das sollte nicht passieren. Hast du jetzt eine funktionierende yaml-Datei?
Ich werde in der Dokumentation das jetzt so machen, dass man einfach die 01-netcfg.yaml editieren soll. Dann kennt man ja zumindest ein NIC-Name und kann das nicht mehr falsch machen.
wenn Du so fragst, vermutlich den “falschen” … “Klassisch” wirkte die
Installation auf mich gerade nicht!
Schickst Du uns einen Link auf genau den “richtigen”?
grundsätzlich bin ich kein Freund von Lernvideos, weil diese eine
Lerngeschwindigkeit vorgeben. Meine SchülerInnen weise ich z. B. bei
Recherchaufträgen, wenn ich Sie Lernvideos gucken sehe, stets darauf
hin, dass sie die Zeit im Auge behalten sollen, in der sie ein Ergebnis
vorweisen müssen. Klar KANN man Pause, Vorlauf oder Wiederholen
anklicken … Auch klar: “Diagonal Lesen” will gelernt sein.
Bildschirmfotos mit erläuternden Texten finde ich wesentlich
übersichtlicher und sie sind zudem noch einfacher in guter Qualität zu
produzieren. Sogar drucken könnte man sie.
Vielleicht bin ich in diesem Punkt aber auch zu “old school”
Ich hatte nur die originale yaml. Im Moment ist XCP-ng ohne linuxmuster
Supplemental Pack auf der Platte und ich will als nächstes versuchen,
die auf eine USB-HD heruntergeladenen 7.0 ova zu importieren. Zu der
Anleitung hat Alois bislang das “No” für weitere Supplemental Packs als
Abweichung beschrieben. Mal sehen, wo es das nächste Mal hakt.
Bei “deiner” KVM-Variante sieht es für mich nach Svens Frage im Moment
so aus, als ob der nächste Versuch mit einer anderen Ubuntu Server iso
erfolgen sollte. Any hints?
mit dem “Alternative Installer” passt das Video wieder weitgehend.
Zwei Abweichungen:
Ubuntu Server mit HWE-Kernel installieren fehlt als Option.
Scheint mir logisch, denn diese Option habe ich benötigt, als ich Ubuntu
12.04 Server für lmn 6.x zu einer Zeit installiert habe, als 14.04
bereits verfügbar war. Nur so wurde die damals aktuelle Server-Hardware
optimal unterstützt und es konnte ein neuerer Kernel als 3.2.x
installiert werden. Es wäre aber auch ohne gegangen und ich hätte den
Kernel später jederzeit austauschen können.
Virtual-Machine-Host wird weiterhin nicht als Option zum Ankreuzen
angeboten.
Das scheint ein Problem zu sein, denn virt-convert gibt es nicht. Es
wird mir empfohlen, es mit “apt-get install virtinst” zu installieren.
Soll ich?
Das Problem mit der yaml habe ich gelöst. Offenbar müssen die
IP-Adressen bei br-server in den eckigen Klammern (=Array?) mit einem
Leerzeichen davor und dahinter geschrieben werden. Ob es dort
stattdessen Anführungszeichen sein dürfen, habe ich nicht getestet. Bei
den Schnittstellenbezeichnungen und Search in Anführungszeichen sind
keine Leerzeichen erforderlich.
Dass Ubuntu zwei Minuten darüber nachdenkt, ob es das Netzwerk so
einrichten soll, liegt vielleicht daran, dass ich die interne
Schnittstelle noch nicht mit dem Switch verbunden habe.
Ich habe einiges geändert, v.a. das Video durch screenshots an den entscheidenden Stellen ersetzt.
Jetzt (stunde später) ist sie auch online.
Schau dir die Doku mal an. Ich habe auch noch festgestellt, dass es nicht so einfach ist, den KVM-Host beliebig in die verschiedenen Netze zu setzen. Das Vorgehen bis inklusive Netzwerktest von Firewall und Server muss also noch besser beschrieben werden.
die Bilder und die Anleitung sind jetzt so weit passend, einschließlich
der yaml.
virt-convert verlangt jedoch auch nach “apt install libvirt-bin
qemu-kvm” noch nach “apt install virtinst”, was weitere 92 Pakete anzieht.
Danach konnte ich den Befehl ausführen. Den nächsten Hänger habe ich bei
dem lvcreate:
Volume Group “host-vg” not found
Für die Firewall ist das Verlegen ins LVM ja noch optional, aber der
Server muss doch ins LVM …
Bei mir gibt es bislang /dev/mapper/kvm–vg-root und
/dev/mapper/kvm–vg-swap im Linux LVM /dev/sda1
Wahrscheinlich muss ich den Befehl lvcreate modifizieren. Weißt Du wie?
ok, alles klar. Das muss also auch noch mit in den Befehl davor
deine Volume Group heißt anders, weil du deinen Hostnamen anders gewählt hast und automatisch die Volume group nach dem hostnamen-vg benannt wird, bei dir: „kvm-vg“ (ich kann nicht ganz erkennen ob das ein oder zwei bindestriche sind, weil das ask-forum hier einen langen und einen kurzen draus macht.
dementsprechend rufst du zuerst "vgdisplay -s " auf, dann weißt du wie die volume group heißt und ersetzt überall wo „host-vg“ steht eben durch deinen volume group.
Danke dafür: dann werde ich oben bei der hostnamen-vergabe die Vorwarnung aussprechen und unten wo es dann weitergeht das gesagte einfügen (ersetze „host-vg“ durch „deine-vg“)
Noch eine Frage: Hast du tatsächlich einen Admin-PC angeschlossen und wenn ja wie. Im Moment ist noch ein Haken an der Sache mit dem „server“, so dass man virt-manager auf dem Admin-PC unbedingt benötigt. Evtl. wird das mit einer nächsten Version der Appliances von @thomas gefixt, evtl. bleibt es aber nötig. Und dann muss die Verbindung von Admin-PC zum KVM-Host stehen.
Ich krieg in meiner Testumgebung von VirtualBox aber genau das gerade nicht zum Laufen… WEnn du also einen Admin-PC hast, der im selben Netz wie die „br-red“-Verbindung des KVM-Host ist, sag mal Bescheid, ob das funktioniert.