[Sammelthread] Proxmox Stammtisch

Die Namen helfen da nur bedingt weiter. Man kann ja LVM/ext4 ontop ZFS angelegt haben so wie ZFS ontop einem anderen Dateisystem auf Dateien oder virtuellen Festplatten
Aaaaha!

Also liegt das ganze "LVM" vermutlich auf einem ZFS-Mirror, wenn man die "Standard-Installation" relativ default druchklickt, wenn ich richtig verstehe.
Muss ich später dann nochmal aufmerksamer machen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Proxmox muss man erst von ZFS überzeugen.
(Ist halt Linux, da ist ZFS ein Extra und nicht default)

local-lvm unter Storage ist LVM/ext4 als Basis
Man muss ZFS mit "add" unter "Storage" hinzufügen um zfs beim anlegen einer VM zu nutzen
VMs kann man von local-lvm zu zfs migrieren.

1735042090331.png




die Grundzuordnung der Platten zu LVM bzw ZFS

1735042463905.png


Um nachzusehen ob eine virtuelle Platte auf lvm-thin oder zfs liegt

1735043660599.png
 
Zuletzt bearbeitet:
Oh Gott... es wird nicht besser in meinem Kopf... :rolleyes: :d

Auf /sdc ist noch ein altes Win7, daher das NTFS...

Ist das, was hier LVM heißt nun mit einem Ext4 drunter?

1735043679680.png



Sorry, dass ich mich so anstelle, und vielen Dank für deine/eure Geduld. Echt lieb von dir/euch.
 
Ist das, was hier LVM heißt nun mit einem Ext4 drunter?

Ich muss mir das auch erst selber zurechtrücken weil jede VM Plattform das etwas anders handhabt. Bei VMware ist eine virtuelle Platte normalerweise eine Datei auf einem Dateisystem.

Wenn man eine VM in Proxmox auf local-lvm anlegt, so wird damit nur eine Partition auf der physikalischen Platte definiert und dann mit einem VM Dateisystem formatiert. local-lvm sind also Plattenbereiche und kein ext4 Dateisystem und das VM Dateisystem liegt nicht auf ext4 sondern "raw" auf der Platte.

Mit ZFS zvol ist das anders. Da liegt immer ZFS unter dem VM Dateisystem.
 
Zuletzt bearbeitet:
Aaaaha!

Also liegt das ganze "LVM" vermutlich auf einem ZFS-Mirror, wenn man die "Standard-Installation" relativ default druchklickt, wenn ich richtig verstehe.
Muss ich später dann nochmal aufmerksamer machen.

Nein, ZFS und LVM werden vom installaller nicht gemischt.

Truenas auf Proxmox würde ich meiden. Du verbaust dir damit viele Optionen, bzw macht es unnötig kompliziert. Du kannst z.b. Für deine Bilder, Musik, Filme entsprechende ZFS Datasets anlegen und diese z.B. per LXC smb Server mit deinen Clients teilen. In weiteren Containern wie Nextcloud, Plex, Photoprism, Seafile,... kannst du die selben Datasets als Mountpoint einbinden und du hast alles schön an einer zentralen Stelle. Sprich Bilder oder Musik die du per SMB oder einer Smartphone App auf den Server schiebst sind sofort auch in den anderen Applikationen verfügbar. Irgendwelche kruden Lösungen mit smb oder nfs shares zwischen den Containern sind damit nicht notwendig.
 
Noob hier und mehr eine theoretische Frage. Wenn ich VMs habe, die selbst vorzugsweise auf ZFS setzen, sollte ich diese dann besser auf LVM-Thin platzieren statt auf ZFS oder diese selbst explizit nicht mit ZFS betreiben oder dann doch ZFS auf ZFS machen?
Hab ich was vergessen? 😁

Ich als Noob finde die GUI den Storage betreffend eine mittlere Katastrophe bei Proxmox, aber das unabhängig von obiger Fragestellung.
 
Noob hier und mehr eine theoretische Frage. Wenn ich VMs habe, die selbst vorzugsweise auf ZFS setzen, sollte ich diese dann besser auf LVM-Thin platzieren statt auf ZFS

das wäre die Methode mit der geringsten write amplification und die etwas schnellere

oder diese selbst explizit nicht mit ZFS betreiben

Dann ohne Crash Protection (CoW), Snaps, Prüfsummen und bitrot protection in der VM?
Kein guter Plan

oder dann doch ZFS auf ZFS machen?

Wäre das einfachste, man könnte den RAM global als cache nutzen, global sync write machen und einfach mit ZFS replication sichern (dann die VM config-Datei in /etc/pve/ nicht vergessen). Auch Hybrid Pool ist was feines.

Ich als Noob finde die GUI den Storage betreffend eine mittlere Katastrophe bei Proxmox, aber das unabhängig von obiger Fragestellung.

Sehe ich auch so, liegt halt mit an Linux und der Vielfalt der Optionen jenseits von ZFS
Der Ausweg ist ZFS mit einer Storage VM (kostet extra Resourcen) oder ein ZFS web-gui addon für Proxmox (cockpit/poolsman, mein napp-it cs etc)
 
Truenas auf Proxmox würde ich meiden. Du verbaust dir damit viele Optionen, bzw macht es unnötig kompliziert.
Ich verstehe schon, habe den Tip schon öfter gelesen und beherzige und verstehe das auch.
Da ich mit TrueNAS aber sehr gut zurechtkomme und das NAS auch benötige, werde ich das vorerst lassen, und mich parallel dazu mit dem "Proxmox-NAS" spielen... und dann irgendwann umsteigen, wenn ich das soweit im Griff habe. TrueNAS läuft ja auch als VM gut, haben viele Leute so, also warum (erstmal) nicht.
Ein Schritt nach dem anderen für mich.

Danke mal für eure Infos, weiter gehts.

sdb ist das Drive, auf dem ich Proxmox installiert hab (ziemlich default)..
1735131340770.png
lsblk -f gibt mir etwas mehr Einblick:

Wurde hier bei der Installation erstmal LVM (und die EFI) auf sdb erstellt?
Dann in dem LVM ein paar Partitionen?
- swap (braucht man den, deaktiviert man den...?)
- root (habs offenbar als ext4 installiert testweise... evtl. weil ich grad nur wenig RAM im Testrechner hab)
- pve-data - das thin-LVM?
=> In der Konfig also nix auf ZFS? Seh ich das richtig?
1735131588041.png
 
Hallo zusammen und frohe Weihnachen in die Runde,

ich habe gerade mal ein wenig mit meinem Proxmox Host rumgespielt und bin auf ein Problem oder vermutlich einfach
nur falsches Vorgehen von mir gestossen.

Ich war so naiv zu denken, dass ich 'ne Mellanox ConnectX-3 pro ja sicher ohne Probleme unter einem aktuellen PVE 8.3.2
(EFI und Secure boot) bertreiben kann. Aber offenbar ist es doch nicht so trivial.

Ich hatte bereits die MFT Tools von der nvidia Seite installiert (auch in der Version 4.22, wie empfohlen, da die letzte Version
mit ConnectX-3 und ConnectX-3 pro suport). Beim starten des tools mit mst start bricht er schon mit dem Fehler ab 'mst_pci driver not found'.

Ein lspci zeigt die Karte aber ohne Problem an. Wird die Karte überhaupt noch out of the box unterstützt, muss eventuell
manuell Treiber installieren oder ist das ganze zum scheitern verurteilt. Wobei er ja irgendwas zu finden und zu machen scheint.

Dec 25 12:12:14 pve kernel: mlx4_core: Mellanox ConnectX core driver v4.0-0
Dec 25 12:12:14 pve kernel: mlx4_core: Initializing 0000:01:00.0
Dec 25 12:12:14 pve kernel: mlx4_core 0000:01:00.0: DMFS high rate steer mode is: disabled performance optimized steering
Dec 25 12:12:14 pve kernel: mlx4_core 0000:01:00.0: 63.008 Gb/s available PCIe bandwidth (8.0 GT/s PCIe x8 link)
Dec 25 12:12:14 pve kernel: mlx4_en: Mellanox ConnectX HCA Ethernet driver v4.0-0
Dec 25 12:12:14 pve kernel: mlx4_en 0000:01:00.0: Activating port:1
Dec 25 12:12:14 pve kernel: mlx4_en: 0000:01:00.0: Port 1: Using 8 TX rings
Dec 25 12:12:14 pve kernel: mlx4_en: 0000:01:00.0: Port 1: Using 8 RX rings
Dec 25 12:12:14 pve kernel: mlx4_en: 0000:01:00.0: Port 1: Initializing port
Dec 25 12:12:14 pve kernel: mlx4_en 0000:01:00.0: registered PHC clock
Dec 25 12:12:14 pve kernel: mlx4_en 0000:01:00.0: Activating port:2
Dec 25 12:12:14 pve kernel: mlx4_en: 0000:01:00.0: Port 2: Using 8 TX rings
Dec 25 12:12:14 pve kernel: mlx4_en: 0000:01:00.0: Port 2: Using 8 RX rings
Dec 25 12:12:14 pve kernel: mlx4_en: 0000:01:00.0: Port 2: Initializing port
Dec 25 12:12:14 pve kernel: <mlx4_ib> mlx4_ib_probe: mlx4_ib: Mellanox ConnectX InfiniBand driver v4.0-0
Dec 25 12:12:14 pve kernel: <mlx4_ib> mlx4_ib_probe: counter index 2 for port 1 allocated 1
Dec 25 12:12:14 pve kernel: <mlx4_ib> mlx4_ib_probe: counter index 3 for port 2 allocated 1
Dec 25 12:12:14 pve kernel: mlx4_core 0000:01:00.0 enp1s0: renamed from eth0
Dec 25 12:12:14 pve kernel: mlx4_core 0000:01:00.0 enp1s0d1: renamed from eth1
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:18:55 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:49:20 pve kernel: mlx4_core 0000:01:00.0 enp1s0: entered allmulticast mode
Dec 25 13:49:20 pve kernel: mlx4_core 0000:01:00.0 enp1s0: entered promiscuous mode
Dec 25 13:49:20 pve kernel: mlx4_en: enp1s0: Steering Mode 1
Dec 25 13:49:20 pve kernel: mlx4_en: enp1s0: Link Down
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: /dev/mem,kmem,port is restricted; see man kernel_lockdown.7
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:54:50 pve kernel: Lockdown: mlxfwmanager: direct PCI access is restricted; see man kernel_lockdown.7
Dec 25 13:56:17 pve kernel: mlx4_core 0000:01:00.0 enp1s0: left allmulticast mode
Dec 25 13:56:17 pve kernel: mlx4_core 0000:01:00.0 enp1s0: left promiscuous mode

/EDIT
Hat sich mittlerweile soweit aufgeklärt. Der Zugriff mit den Mellanox Tools ging erst gar nicht, weil wohl secure boot im BIOS
akitivert war. Hat man es ausgeschaltet, liessen sich diese auch verwenden. Einzig die etwas merkwürdige unterschiedliche
Bezeichnung der beiden Ports war erst noch etwas irritierend. Aber ein zuweisen zur Bridge und er konnte dann
verwendet werden. Nun muss noch ein passendes Bracket gedruckt werden, damit die Karte dauerhaft drin bleiben kann.

root@pve:/etc/network# mlxfwmanager
Querying Mellanox devices firmware ...

Device #1:
----------

Device Type: ConnectX3Pro
Part Number: 779793-B21_0A
Description: HP Ethernet 10G 2-port 546SFP+ Adapter
PSID: HP_1200111023
PCI Device Name: /dev/mst/mt4103_pci_cr0
Port1 MAC: 9cdc714cb7a0
Port2 MAC: 9cdc714cb7a1
Versions: Current Available
FW 2.42.5044 N/A
CLP 8025 N/A
PXE 3.4.0754 N/A
UEFI 14.11.0048 N/A

Status: No matching image found


root@pve:/etc/network# mlxconfig -d /dev/mst/mt4103_pciconf0 q

Device #1:
----------

Device type: ConnectX3Pro
Device: /dev/mst/mt4103_pciconf0

Configurations: Next Boot
SRIOV_EN True(1)
NUM_OF_VFS 16
PHY_TYPE_P1 XFI(2)
XFI_MODE_P1 _10G(0)
FORCE_MODE_P1 False(0)
PHY_TYPE_P2 XFI(2)
XFI_MODE_P2 _10G(0)
FORCE_MODE_P2 False(0)
LOG_BAR_SIZE 5
BOOT_OPTION_ROM_EN_P1 False(0)
BOOT_VLAN_EN_P1 False(0)
BOOT_RETRY_CNT_P1 0
LEGACY_BOOT_PROTOCOL_P1 None(0)
BOOT_VLAN_P1 1
BOOT_OPTION_ROM_EN_P2 False(0)
BOOT_VLAN_EN_P2 False(0)
BOOT_RETRY_CNT_P2 0
LEGACY_BOOT_PROTOCOL_P2 None(0)
BOOT_VLAN_P2 1
IP_VER_P1 IPv4(0)
IP_VER_P2 IPv4(0)
CQ_TIMESTAMP True(1)
STEER_FORCE_VLAN False(0)


root@pve:~# lspci | grep Mellanox
01:00.0 Ethernet controller: Mellanox Technologies MT27520 Family [ConnectX-3 Pro]
 
Zuletzt bearbeitet:
Wurde hier bei der Installation erstmal LVM (und die EFI) auf sdb erstellt?
Dann in dem LVM ein paar Partitionen?
- swap (braucht man den, deaktiviert man den...?)
- root (habs offenbar als ext4 installiert testweise... evtl. weil ich grad nur wenig RAM im Testrechner hab)
- pve-data - das thin-LVM?
=> In der Konfig also nix auf ZFS? Seh ich das richtig?

das ist die Standardkonfig mit LVM, somit kein ZFS.

pve-data ist idR als "thin" angelegt. Du kannst dir die Konfig unter /etc/pve/storage.cfg im Detail ansehen.
 
Oh Gott, könnt ihr mir mit meiner Demenz helfen?
1735146149633.png
Man ist doch im UEFI irgendwie ins "Bios" des HBA (9400-16i, Lenovo 430) gekommen... imho war ich da selbst auch schon drin, und hatte den quasi ins UEFI integriert.
Was muss ich tun, damit ich dort hin komm? Gefunden wird er ja offenbar...

Also... per PCIe-Passthrough an eine VM vergeben wiill ich ihn.
 
Ich habe seit vielen Monden einen Proxmox Server auf Basis eines Fujitsu ThinClients am laufen.
Ohne Probleme.

Habe nun auf ein Lenovo ThinkCentre M910x mit Intel i5-7500 16 GB DDR4 Ram, einer Patriot P320 128GB als Proxmox Platte und eine Seagate Barracuda 500 GB SATA Platte für die VMs umgerüstet.
Auf dem ThinkCentre laufen 2 VMs.

Nun passiert es alle paar Tage, dass die Weboberfläche und auch SSH auf den Proxmox Server nicht mehr laufen.
Anpingbar ist die Maschine und auch die VMs laufen ohne Probleme weiter.
Im Systemlog und auch journalctl ist absolut nichts zu finden, was die Ursache sein könnte.

Kernel Version Linux 6.8.12-5-pve
pve-manager/8.3.2/

Jemand eine Idee?
Ggf. ne Idee welche Logs relevant sind?
/va/log/ habe ich alles durch und nichts gefunden.
 
Laufen denn die Services noch und reagieren nicht mehr oder sind die Services wirklich Tod? Was sagt ihr in systemctl status zum jeweiligen Service?
So ne die Services denn lokal noch erreichbar?

Noch eine Idee, vielleicht verschluckt sich das Netzwerk und die Services das Netzwerk verlieren.
 
Laufen denn die Services noch und reagieren nicht mehr oder sind die Services wirklich Tod? Was sagt ihr in systemctl status zum jeweiligen Service?
So ne die Services denn lokal noch erreichbar?

Noch eine Idee, vielleicht verschluckt sich das Netzwerk und die Services das Netzwerk verlieren.
Muss ich beim nächsten mal schauen.
Muss ich Monitor und Tastatur mal anschließen.
 
Sind schon Backups auf dem DS vom PBS ? Ansonsten gibt es nichts zu prunen..
Ich habe 7 VMs auf dem pve, welche täglich auf nem Fijitsu 1HE Server abgezogen werden. Die müssen meiner Meinung nach, nach der festgelegten retentionpolicy geprunt werden.
Die Backup Jobs laufen ja, was ich gerade aber noch nicht richtig verstehe, warum in dem pve log die Prune Jobs überhaupt mit auftauchen. Nach meinem Verständnis ist doch der PBS fürs Aufräumen zuständig oder?
 
Mal zum Verständnis:
Aktuelle konfig wie im Screenshot.
Ich würde gerne enps50 aber abklemmen und stattdessem dem imci port an den Switch hängen. Einfach machen oder muss ich die konfigs tauschen?
 

Anhänge

  • Bild_2024-12-26_230812381.png
    Bild_2024-12-26_230812381.png
    6,6 KB · Aufrufe: 31
Ich habe 7 VMs auf dem pve, welche täglich auf nem Fijitsu 1HE Server abgezogen werden. Die müssen meiner Meinung nach, nach der festgelegten retentionpolicy geprunt werden.
Die Backup Jobs laufen ja, was ich gerade aber noch nicht richtig verstehe, warum in dem pve log die Prune Jobs überhaupt mit auftauchen. Nach meinem Verständnis ist doch der PBS fürs Aufräumen zuständig oder?
Du brauchst 2 Tasks: Prune + Garbage Collection - prume "markiert" die nicht mehr bnötigten, GC gibt frei... aber nur für Chunks die aälter sind als 48 Stunden, weil der PBS sich daran "bedient" wenn neue Backups da was von brauchen können. Wenn man einen top aktuelle Stand haben will, muss man nach prune erst über die shell irgend so einen "touch 1-Zeiler" abschiessen, der das Datum manipuliert, damit GC dann vollständig entsorgt.
 
Hallo zusammen, ich brauche eure Hilfe weil ich nicht verstehe wie ich es am besten angehe:
ich möchte von einem DDWRT Router zu einem Cloud Gateway Ultra mitsamt neuer IP Adressrange wechseln.
Die IP Adressraumänderung würde ich gerne auch schon vorher gestalten, weiß aber nicht wie ich vorgehen muss um alle Geräte richtig umzuziehen.

Geräte:
- Pihole (Raspberry Zero W) hängt über WLAN (wlan Name möchte ich auch ändern, andere Credentials ebenfalls) und fixed IP, kann ich per config Datei auf der SSD das WLAN ändern nachdem ich den Router/IP Adressraum geändert habe?
- Pihole ist aktuell der DHCP Server, das möchte ich dann wieder auf den Cloud Gateway Ultra laufen lassen, gleichzeitig vergehe ich per static DHCP Lease IP Adressen an Engeräte wie Proxmox Server mitsamt seinen VMs, löse ich diese static DHCP Leases bevor ich wechsel, sodass die Maschinen dann vom neuen Router die neue DHCP Adresse bekomme und dann füge ich die statischen DHCP leases wieder hinzu?
- Pihole übernimmt auch den localen Domain Name "home" und ich habe entsprechend local DNS records angelegt für bspw. nextcloud.home, nginx.home usw., nehm ich die auch raus und lasse die über den Cloud Gateway Ultra laufen, oder sollte ich das beser im Pihole lassen? ich glaube es gibt im Pihole ein Conditional Forwarding für DNS Anfragen wenn der Pihole nicht der DHCP Server ist, dafür ist vermutlich der DNS Lookup?
- Proxmox bekommt einen DHCP Lease, zeigt mir aber unter Network die Linux Bridge mit einer festen? IP Adresse an statt irgendwo DHCP anzuzeigen, ist das so richtig? ist länger her, dass ich ´den proxmox server aufgesetzt habe, bin gerade etwas lost.
Bildschirmfoto 2024-12-28 um 11.21.39.png
 
Statische DHCP Adressen hängen an der MAC Adresse. Ich würde im UCG erstmal div. vLANS anlegen (z.B. intern, management, IOT, Guest), dann die Isolierung prüfen (inertn darf nach Guest, aber nicht umgekehrt etc), und dann die Geräte umklemmen, und schauen ob sich das alles richtig zusortiert, ggf halt fixe IPs zuweisen, da weios man was man hat.
 
Kann man den Host/Node eigentlich einem VLAN zuordnen? Ich hatte damit in der Vergangenheit immer Probleme, so etwas umzustellen, und verzichte daher lieber darauf.
 
Ich habe seit vielen Monden einen Proxmox Server auf Basis eines Fujitsu ThinClients am laufen.
Ohne Probleme.

Habe nun auf ein Lenovo ThinkCentre M910x mit Intel i5-7500 16 GB DDR4 Ram, einer Patriot P320 128GB als Proxmox Platte und eine Seagate Barracuda 500 GB SATA Platte für die VMs umgerüstet.
Auf dem ThinkCentre laufen 2 VMs.

Nun passiert es alle paar Tage, dass die Weboberfläche und auch SSH auf den Proxmox Server nicht mehr laufen.
Anpingbar ist die Maschine und auch die VMs laufen ohne Probleme weiter.
Im Systemlog und auch journalctl ist absolut nichts zu finden, was die Ursache sein könnte.

Kernel Version Linux 6.8.12-5-pve
pve-manager/8.3.2/

Jemand eine Idee?
Ggf. ne Idee welche Logs relevant sind?
/va/log/ habe ich alles durch und nichts gefunden.
Sodale.
Habe mir ein 8" Full HD Monitörchen geholt (ziemlich nice, leicht, portabel mit Gehäuse, klebt jetzt mit Klettverschluss an meinem kleinen Serverschränkchen und habe so direkt die Möglichkeit zu gucken :d) und habe das Problem direkt gesehen

IMG_2546.jpeg

Die NVME wird ejected und read-only wieder eingehangen.

Scheint wohl ein nicht sooooo neues Problem zu sein

Werde dem dann mal auf die Spur gehen.
Smart Werte der NVME sehen gut aus.
 
Mal zum Verständnis:
Aktuelle konfig wie im Screenshot.
Ich würde gerne enps50 aber abklemmen und stattdessem dem imci port an den Switch hängen. Einfach machen oder muss ich die konfigs tauschen?
Da hier keine Antwort kam hab ich einfach bei vmbr0 die Netzwerkkarte von vmbr1 ausgewählt und vmbr1 gelöscht. Jetzt hab ich gar keinen Zugriff mehr auf das Webinterface. Die Fritzbox zeigt nun auch 2 Geräte mit der *54 Ip Adresse an. Wie kann ich das nun retten? Danke :hail:
 
Jemand hier OPNsense/OpenWrt auf Proxmox laufen? Und nutzt jemand Router-On-A-Stick Konfiguration? Also an nen Switch mit Trunks angebunden, und WAN in einem VLAN?
 
Ja @Knogle ich nutze das setze ohne Probleme seid mehreren Jahren.
WAN kommt von einer FRITZ!Box in den Switch als untagged VLAN und wird Tagged an Proxmox gegeben.
Proxmox fischt das raus und stellt das auf einer vmbr bereit.
 
Moin zusammen,

ich versuche gerade Paperless in einem LXC aufzusetzen und möchte gerne die Dokumente auf meinem ZFS Share von Proxmox abspeichern.

Hat dafür jemand eine Lösung?

Mittels MountPoint hat Paperless keine Schreibrechte oder kann ich da noch etwas einstellen?
 
Moin zusammen,

ich versuche gerade Paperless in einem LXC aufzusetzen und möchte gerne die Dokumente auf meinem ZFS Share von Proxmox abspeichern.

Hat dafür jemand eine Lösung?

Mittels MountPoint hat Paperless keine Schreibrechte oder kann ich da noch etwas einstellen?

Du musst die Berechtigungen im Filesystem anpassen. Im Container den Order an den User geben unter dem Paperless läuft.
 
Das Thema mit extremen Paketverlust was ich hatte, zwischen 10-40%.
Lag an meiner Konfig mit kaskadierten bridges.

Habe gedacht, ok bond0 --> Bridge, dann auf der Bridge ein VLAN drauf, und auf's VLAN nochmal ne Bridge z.b. vmbr200.



Code:
root@millenium-gbe31:~# cat /etc/network/interfaces
# network interface settings; autogenerated
# Please do NOT modify this file directly, unless you know what
# you're doing.
#
# If you want to manage parts of the network configuration manually,
# please utilize the 'source' or 'source-directory' directives to do
# so.
# PVE will preserve these directives, but will NOT read its network
# configuration from sourced files, so do not attempt to move any of
# the PVE managed interfaces into external files!

auto lo
iface lo inet loopback

auto eno1
iface eno1 inet manual

auto eno2
iface eno2 inet manual

auto eno49
iface eno49 inet manual

auto eno50
iface eno50 inet manual

auto bond0
iface bond0 inet manual
bond-slaves eno1 eno2
bond-miimon 100
bond-mode 802.3ad
bond-xmit-hash-policy layer2+3

auto vmbr0
iface vmbr0 inet static
address 192.168.1.10/24
gateway 192.168.1.1
bridge-ports bond0
bridge-stp off
bridge-fd 0
bridge-vlan-aware yes
bridge-vids 2-4094

auto vmbr0.110
iface vmbr0.110 inet manual
#MGMT

auto vmbr0.200
iface vmbr0.200 inet manual
#Virtual

auto vmbr110
iface vmbr110 inet static
address 172.20.64.10/19
bridge-ports vmbr0.110
bridge-stp off
bridge-fd 0
 
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