[Sammelthread] Proxmox Stammtisch

ZFS Web-gui für Proxmox

Napp-it cs ist eine web-gui für OpenZFS servergroups (beliebiges OS). Es läuft unter Windows zum Managen von Storage Spaces und ZFS. Es kann remote andere ZFS Servers wie Free-BSD, OSX oder Linux/Proxmox managen.

Es kam der Wunsch auf es direkt unter Free-BSD, Illumos, OSX oder Linux/Proxmox laufen zu lassen.

Habe mal eine erste Beta hochgeladen:

1. download https://www.napp-it.de/doc/downloads/csweb-gui.zip and unzip csweb-gui.zip
2. upload folder csweb-gui to /var on Linux/Proxmox/Illumos (-> /var/csweb-gui, use WinSCP)
3. start a cgi capable webserver
for basic tests you can use the included mini_httpd
4. open Putty as root and run (copy/paste command with mouse rightclick)
sh /var/csweb-gui/data/webserver/mhttpd/debian/mini-httpd.sh
(on Illumos, replace /debian/ with /illumos/)

5. Open a browser with http://serverip:81 (mini_httpd is configured for http only)

On other platforms ex OSX or for https:
use a cgi/Perl capable webserver ex apache or lighttpd

napp-it cs is free for noncommercial use
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich kenne das Thema mit den MAC-Adressen und weiß das das nicht notwendig sein wird (ich fummel an dem Ding nicht mehr rum, das hab ich mir abgewöhnt + backup proxmox).
Eins noch: wie schon erwähnt, werden bei Änderungen der Hardware zusammensetzung auf dem PCIe Bus die Gerätenamen neu vergeben. Änderungen müssen nicht zwingend "aktiv" also duch den User geschen, sondern erfolgen auch bei Hardware defekt. Sprich, wenn eine SSD oder Netzwerkkarte geht kaputt, klappt Dir auch das Management Interface weg, weil alelsneu sortiert worden ist, und die Interface Namen nicht mehr zur interfaces.conf passen. Das muss man dann in solchen Fällen auf dem Schirm haben und sich direkt per KVM/IPMI einloogen und prüfen. Oder halt üer MAC bezogene Inferterface Namen von vorneherein fest nageln.
 
@gea kannst du vielleicht mal ein (paar) Youtube-Videos zu nappit machen?
Bitte bloss nicht... Text mit Bildern ist 100x effizienter und die Doku ist jetzt schon sehr gut. Man muss halt mal reinschauen...
 
@gea kannst du vielleicht mal ein (paar) Youtube-Videos zu nappit machen?

Ja das ist wohl der Zeitgeist. Statt "lade den Ordner hoch und starte das Ding mit Aufruf X" braucht man TickTock oder Youtube Videos die das zeigen. Da sich die Welt immer schneller dreht, immer neue davon weil die alten ja nicht mehr den neuesten Stand bieten oder man ja als Influencer im Gespräch bleiben muss. Wobei die eigentliche Information meist eh nicht im Vordergrund steht, Hauptsache Unterhaltung und man muss nicht lesen.

Es gibt einige über 10 Jahre alte Videos zu napp-it unter Solaris/Illumos. Die sind immer noch gültig. Geht halt nichts über Minimaltechnologie, so wie früher als Apple noch den Zusatz "Computer" im Namen hatte. Da war es normal, eine Software durch Kopieren eines Ordners zu installieren. Deinstallieren ist Löschen des Ordners. So ist napp-it nach wie vor.
 
Eins noch: wie schon erwähnt, werden bei Änderungen der Hardware zusammensetzung auf dem PCIe Bus die Gerätenamen neu vergeben. Änderungen müssen nicht zwingend "aktiv" also duch den User geschen, sondern erfolgen auch bei Hardware defekt. Sprich, wenn eine SSD oder Netzwerkkarte geht kaputt, klappt Dir auch das Management Interface weg, weil alelsneu sortiert worden ist, und die Interface Namen nicht mehr zur interfaces.conf passen. Das muss man dann in solchen Fällen auf dem Schirm haben und sich direkt per KVM/IPMI einloogen und prüfen. Oder halt üer MAC bezogene Inferterface Namen von vorneherein fest nageln.
Ich habs jetzt ganz pragmatisch gemacht: In der Bridge sind die beiden Onboard-Gbit-NICs und der erste von 2 40g Ports, der zweite ist unbenutzt (da mein NAS auch gerne 40G hätte). Selbst wenn der 40g Port mir wegbricht, hab ich immer noch Zugriff.
Trotzdem danke für deine Hinweise, ich mag zwar etwas bockig klingen, aber ich hab das Thema ja in der Vergangenheit einmal gemacht gehabt (damals um vernünftige MACs auf den VFs zu haben, different usecase, same shit). Wenn alles läuft widme ich mich dem vielleicht nochmal.
 
Ich versuche heute Nacht mal SR-IOV mit den 4 X540ern im Proxmox ans Laufen zu bekommen, ich hab das Gefühl, die virtuellen NICs bremsen meine NAS-Performance in der VM...
Dann bekommt jede VM ne virtuelle X540.
Kann ich im ProxMox dann irgendwie die VLANs steuern?
(nicht jede VM braucht jedes VLAN, aber die Karten sind aufm Switch halt im Trunk (aktuell je 2 in einem Bond, einmal für iSCSI und einmal für "normalen" VM-Verkehr), wie verhält sich das bei den virtuellen NICs?)
 
Ok, hat geklappt.
Aaaber:
Nie, nie, NIEMALS eine virtuelle Netzwerkkarte aus der VM entfernen, wenn echte HW durchgereicht ist!!!!!!
Kurzer Schock-Moment, nachdem ich die alte vNIC live aus der VM entfernt hatte, beschwerte sich ProxMox, dass er nicht hotpluggen konnte.
Daraufhin flogen ALLE Platten aus ALLEN Pools in der VM. 😱:wall:
Hart aus/ein der VM hat dann geholfen, aber aua, ohne ZFS möchte ich das nicht nochmal machen.
Zum Glück keinen großen Traffic drauf gehabt und keine Fehler auf dem FS. *puuuh*

Es lief auf ein einfaches "echo 4 > /sys/bus/pci/devices/0000:04:00.0/sriov_numvfs" raus, die bisherige Konfig bleibt davon unbeeindruckt (also auch der Bond).
Daraufhin hat man vier neue Karten, die man den VMs dann einfach zuweisen kann.
Jetzt muss ich das nur noch persistieren.
Der Umweg mit dem Service ist mir zu kompliziert, ich versuchs mal mit den sysfsutils...
//Edith2: Hab mich breitschlagen lassen und nen sr-iov.service angelegt...

Problem damit ist nur noch:
Ich reiche hier komplette Trunks durch...
Beim iSCSI-VLAN kein Problem, das basiert auf statischen IPs und wird nicht geroutet.
Aber die anderen VLANs kann ich so nicht einfach durchreichen, weil dann immer alle VMs alle VLANS sehen könnten (muss innerhalb der VM konfiguriert werden)...

//Edith:
Zum Thema was bringts?!
1738016420079.png

Gefühlt ist der wahlfreie Zugriff auf ext4 on zfs um das 5..10fache oder so gestiegen.
Gesichert ist die (Gesamt-)CPU-Last auf dem Proxmox von 14 % auf 7 % (40 Kerne) beim patchen gefallen.
Vergleich hinkt zwar ein wenig (14 % waren es bei der Windows-Version NTFS on ZFS) aber gefühlt ist die Performance bei random access jetzt wesentlich größer.
Im Burst war ich schon vorher mit 640 MB/s nah am Maximum der 6 Platten im Z2.

Der aktuelle Stalker 2 Patch hat unter Windoofs ca. 25 min gebraucht und jetzt unter Linux ca. 15 min.
(Zwei verschiedene Installationen zum testen, man hats ja. :fresse:)
 
Zuletzt bearbeitet:
Ich habe da ein Problem:

ich habe folgende /etc/network/interfaces:

Code:
auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

auto enp2s0
iface enp2s0 inet manual
        mtu 9000

auto vmbr2
iface vmbr2 inet static
        address 192.168.0.12/24
        gateway 192.168.0.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#eno1

auto vmbr3
iface vmbr3 inet static
        address 192.168.20.12/24
        bridge-ports eno1.20
        bridge-stp off
        bridge-fd 0
#VLAN20 1G

auto vmbr5
iface vmbr5 inet manual
        bridge-ports eno1.30
        bridge-stp off
        bridge-fd 0
#VLAN30

auto vmbr6
iface vmbr6 inet manual
        bridge-ports eno1.10
        bridge-stp off
        bridge-fd 0
#VLAN10

auto vmbr7
iface vmbr7 inet manual
        bridge-ports eno1.50
        bridge-stp off
        bridge-fd 0
#VLAN50 1G

auto vmbr0
iface vmbr0 inet manual
        bridge-ports eno2
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#eno2

auto vmbr8
iface vmbr8 inet static
        address 192.168.40.12/24
        bridge-ports eno2.40
        bridge-stp off
        bridge-fd 0
#VLAN 40 - Cluster

auto vmbr1
iface vmbr1 inet static
        address 192.168.30.12/24
        bridge-ports enp2s0.30
        bridge-stp off
        bridge-fd 0
        mtu 9000

auto vmbr10
iface vmbr10 inet manual
        bridge-ports enp2s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes
        bridge-vids 2-4094
#10G

auto vmbr4
iface vmbr4 inet static
        address 192.168.50.12/24
        bridge-ports enp2s0.50
        bridge-stp off
        bridge-fd 0
        mtu 9000
#VLAN50 10G

Nun habe ich per Webgui eine Synology Diskstation (192.168.50.9) mittels NFS verbunden.

Wenn ich nun Daten vom Proxmox-Server auf die Synology verschieben will, geht das so:
Proxmox sendet von VLAN1 sich selber auf VLAN10 die Daten zu. Das dauert dann bis der RAM voll ist.
Erst dann sendet Proxmox die Daten von VLAN50 auf die Synology.

Warum geht es da diesen Umweg? Mit anderen Shares, die ich per Smb gemountet habe, passiert das nicht?
 
Hm, wenn ich das hier so lese "über PCI Bus werden bei Änderung/Defekt einfach die Gerätebezeichnung durchgewürfelt", dann habe ich etwas Bedenken von "TrueNas bare metal" auf Proxmox + VM's zu wechseln.

Gibt es eigentlich irgendwo ein gutes/verlässliches HowTo für eine ordentliche/"stabile" Grundinstallation von Proxmox!?
(Vom obigen Thema habe ich nämlich bisher noch nie irgendwo was gelesen.


Danke!


LG
 
Wo ist das Problem?
Es gibt in Debian die Möglichkeit, konsistente Gerätebezeichner ( enp(x)s(y)f(z)v(a) ) für Netzwerkkarten zu erstellen, Drops gelutscht.
Und zwar sowohl in TrueNAS als auch Proxmox, da ja beide auf Debian setzen.
Das führt dann zum nächsten Problem, wenn sich deine Hardware ändert, besteht die Möglichkeit, dass sich die Busnummer bestehender Geräte ändert.

Falls du mein Problem mit den verlorenen Platten meinst, ka, was das war.
ZFS hats aber abgefangen.

Ich denke, meine Grundinstallation von ProxMox ist schon stabil.
Anleitung direkt aus der Dokumentation.

In der Tat komme ich momentan ein wenig von den VMs weg, die letzten 5..6 Services, die ich installiert habe, waren Docker-Container.
Mit ziemlicher Sicherheit kann ich fast alle restlichen VM-basierten Services auch locker auf Docker (haha, Wortspiel) umstellen.

Sind momentan:
für die gibts ziemlich sicher nen Docker:
Nextcloud
Dokuwiki
LibreNMS
Redmine
Jellyfin

ka obs nen Docker für die gibt:
Lyrion Music Server (aka ex Logitech Slimserver)
HomeAssistant
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh