Jump to content

Ford Prefect

Members
  • Posts

    4,326
  • Joined

  • Last visited

  • Days Won

    10

Ford Prefect last won the day on May 20 2023

Ford Prefect had the most liked content!

Converted

  • Gender
    Undisclosed
  • Personal Text
    Don't Panic!

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

Ford Prefect's Achievements

Experienced

Experienced (11/14)

673

Reputation

42

Community Answers

  1. ...schonmal roundcube webmail angeschaut?
  2. Genau. USB ist etwas spezieller, weil da - wenn peer IOMMU - der Controller durchgereicht werden muss....Ports durchreichen ist ein anderer Mechanismus. IOMMU "durchreichen" geht immer auf Ebene PCIe...also immer der ganze Controller...egal ob NIC, USB-Karte, dGPU, SATA... OK, das ist dann Pech. Hängt von der Hardware ab...die meisten Intel-Nics können es. Gibt hier sicherlich einige Beispiele...IOMMU geht quasi in den Settings (Tools -> SystemDevices ...da kannst Du die Geräte markierenn und nach einen Reboot sind sie aus dem unraid Host verschwunden und können dann in einer VM hinzugefügt werden). ZB bei mir: ich habe hier 3 von 6 NICs markiert ....und in meiner Router VM wieder aktiviert Nein und Nein..allein alle vNICs teilen sich die PCIe-Bandbreite des realen NIC...die andere Seite sieht einen NIC. Ohne dedizierten PCIe-baserten Controller auf Deinem System schwer.
  3. Im Inneren des Switch sind die immer getagged. Port-Based bedeutet: das Pakete, welchen von extern auf den Port treffen und selbst untagged sind, mit der PVID getagged werden und mit dieser ID in den Switch gehen Das bei Paketen, welche über den Port den Switch verlassen die VLAN-Tags - je nach Konfig des Port nur die PVID - entfernt werden. Port based VLAN bedeutet hier, das alle VAN-tags entfernt werden. mit Port based VLAN wird der Switch quasi entsprechend der Aufteilung der PVIDs auf den Ports geteilt, wodurch im Inneren dann eben nur Ports mit gleicher ID untereinander kommunizieren können. ...die die eine VM. Der NIC wird quasi in die VM "eingebaut". Ich habe für diesen Zweck eine Intel-T4 eingebaut. Eine Alternative, um Ports quasi zu vervielfältigen wäre ein NIC, der SRV-IO unterstützt. Damit wird der NIC selbst virtualisert und man kann aus einem Port dann 8 unabhängige Ports machen, die einzeln genutzt werden können. Intel-Karten unterstützen das in der Regel. Das ist nur die IP, also L3...auf L2-Ebene, dem virtuellen Switch, sind VM und unraid-host immer noch verbunden. ...auch hier gilt das zuvor gesagte. Siehe dau: https://docs.unraid.net/unraid-os/manual/vm/vm-management/#configure-a-network-bridge Wenn Du VMs von unraid wirklich komplett, zuverlässig separieren willst, dann bleibt nur das Durchreichen des NICs an die VM per IOMMU. Wenn Du nicht genug Netzwerkkarten/Ports installieren kannst: mit SRV-IO auf dem NIC bekommt jeder V-NIC eine eigene IOMMU Gruppe und kann dann auch dediziert an eine VM durchgereicht werden. Nachteil: alles VMS/V-NICs müssen sich die Bandbreite der Karte teilen. Inzwischen sollte SRV-IO bei unraid "unter der Haube" verfügbar sein und eine Konfiguration (Kommanddozeile, GO-File) ohne vorherigen Kernel-Patch möglich sein. Siehe auch: https://forums.unraid.net/topic/103323-how-to-using-sr-iov-in-unraid-with-1gb10gb40gb-network-interface-cards-nics/
  4. Wie meinst Du das genau...ohne VLANs oder hast Du am Switch VLANs aktiviert und die Ports mittels PVIDs "getagged". Es gibt für untagged VLANs kein Konzept...VLANs sind immer tagged...untagged/tagged ist die Unterscheidung am Ein-/Ausgangs-Port eines Switch ob die andere Seite auch VLANs "spricht" (tagged) oder nicht (untagged). Wenn Du keine VLANs nutzen willst, kannst Du die Hardware-Ports per IOMMU an die jeweilige VM durchreichen...dann sind sie für Unraid und die Docker unsichtbar. Das geht aber oft nicht bei on-board Ports, da die dann nicht allein in einer IOMMU-Group sind.
  5. ...total egal, solange die Ports am Switch bzw. Router zum Speed der Unraid-Netzwerkkarte passen. Ja Geschmackssache...mit der ersten Methode musst Du kein Buch führen um zu verhindern, dass IPs nicht doppelt vergeben werden.
  6. Einfach den Server anlassen und ein Balkonkraftwerk installieren. WOL ist für Server-Hardware nicht gemacht...siehe auch: https://forums.developer.nvidia.com/t/wake-on-lan-wol-mcx311a-xcat-not-supported/214479
  7. Ist das System, auf dem diese Browser-Instanz läuft zu diesem Zeitpunkt im gleichen LN-/IP-Segment wir der unraid Host? ...nur mal so am Rande, da Du hier ja auch nen Switch mit Bonding nutzt. Im lokalen LAN, im selben IP-Segment, kommunizieren die Systeme nicht wirklich mit IP, sondern über die MAC Adressen (nur bei der ersten Verbindungsaufnahme passiert ein ARP-Request, um die MAC zur IP herauszufinden). In einem Bonding Scenario ist auch entscheidend unter welcher MAC der unraid Host bekannt ist....evtl steuert Dein Switch zum Chaos bei? Hast Du, bei 3 Ethernet Karten im System alle auf der gleichen Bridge?... welche ist sind im Bond und auf welcher Bridge oder Ethernet liegen Docker und der unraid host? Was ist, wenn Du erstmal nur eine Netzwerkkarte aktivierst - im unraid Host oder auch einfach im Switch die beiden anderen abziehst...wie verhält sich das System dann?
  8. Da die fehlende Disk im Moment emuliert wird, ist ja im Array nicht viel kaputt. jede Daten-Disk hat ihr eigenes Dateisystem und jede Datei ist immer vollständiig auf einer der Disks Die eigentliche Frage ist, was ist mit dem Dateisystem der "verlorenen" Disk evtl. "passiert" ist. Da Du die Zuordnung der einzelnen Disks im Array kennst, würde ich Folgendes machen: Ich nehme mal an, VMs und Apps/Docker liegen auf dem Cache, nicht auf dem Array, oder? Gut wäre, wenn Daten auf dem Array nur "cold storage" wären. backup der Config/des unraid-Stick machen...dezentral sichern. Array stoppen - vorher VM und Docker Dienste stoppen und deaktivieren - vor allem, wenn die auch auf dem Array liegen Tools - New Config, dabei bestehende Zuordnung *nicht* beibehalten Alle Array Daten-Disks sollten nun mit unassigned devices mountbar sein Jede Disks einzeln testen/mounten...die "verlorene" zuerst...bei Problemen Dateisystem reparieren - das sollte, wenn überhaupt, nur bei der "verlorenen" nötig sein. Ist das Dateisystem der "verlorenen" beschädigt, kannst Du beim reparieren Daten verlieren...hoffentlich spricht xfs da im Log etwas sinnvolles zu Dir. Wenn die alle ohne Probleme mounten, bzw. bei der verlorenen das Dateisystem gfls repariert wurde, kannst Du mit den Daten-Disks das Array - zunächst OHNE Parity - neu aufbauen. Hierbei musst Du nichtmal darauf achten, ob die Daten-Disks ihre Position wie zuvor einnehmen/behalten, denn Parity gibt es ja (noch) nicht. Wenn das Array wieder mit allen Daten-Disks läuft, die Parity-Disk hinzufügen und Parity dabei neu bauen lassen. Cache Disks in die Config einbauen und die VM/Docker Dienste wieder starten. Je nach Erkenntnisse zum Dateisystem der "verlorenen" Disk kannst Du ein Backup wieder einspielen/fehlende Dateien wieder ersetzen
  9. Das ist LACP/bonding und hat mit VLANs nix zu tun. Das geht nicht. Bei den Netzwerk-Einstellungen kannst Du VLANs aktivieren Wenn Du VLANs aktiviert hast, kannst Du zB Docker im Custom Network auf br0.20 oder br0.30 mit eigener IP aus dem Segment legen. Das hat auch nix mit VLANs zu tun. Willst Du zwei IP-Segmente auf dem gleichen Interface oder VLANs? Hast Du auch einen VLAN-fähigen Router oder was willst Du mit VLANs bezwecken?
  10. Ja, die Beiträge sind etwas älter, aber das ist die USV-Technik auch...ich habe meine Eaton seit 15 Jahren und den Verbrauch mit einer grossen PV-Anlage kompensiert, statt die USV zu tauschen Ich habe inzwischen das xxte System, aber immer noch die gleiche USV. Evtl. mal Tante Googl nach Testberichten fragen...da ist ja meistens dann heutzutage auch der idle-Verbrauch mitgetestet, weil es sich inzwischen so gehört.
  11. bin jetzt unsicher, was Du suchst. Wenn die USV passt, aber Du nicht weisst ob die Infos zum idle-Verbrauch stimmen...dann kaufen, nen Smart-Plug dazwischen mit Energiemessung und rausfinden...bei nichtgefallen, Rückgabe. Edit: sowas als Smart-Plug---kommt fertig mit Tasmota und muss nicht kalibriert werden.
  12. Meine Disks gehen auch bei ZFS in den Spindown. Scheint bei manchen Systemspezifisch zu sein. ...beschreibe Deine Intention von "einer Art Mirror"...solange es nur 2 Disks sind (1x Daten, 1x Parity) macht unraid auch im Array einen Mirror. Ansonsten gibt es im secondary storage Redundanz nur bei BTRF oder ZFS. snaps nur mit ZFS Redundanz, ausserhakb Array nur BTRFS oder ZFS single Disks im/ausserhaalb des Array: XFS .. will man aber später Redundnz dazubauen lieber gleich ZFS In meiner Erfhrung, von BTRFS kommend, ist ZFS viel zuverlässiger und meine NVMe rennen auch kühler.
  13. ...so war es gedacht...also, nicht zu komplex und vor allem kein USB für produktive Daten. @Firestone mir war nicht klar, dass Du bei Deinen 3SSD schon auf USB zurückgreifen musst. Wenn es Dir um Datensicherheit oder besser Erhöhung der Verfügbarkeit geht kannst Du bei zwei Disks im Spiel, statt Parity auch einen unraid Pool verwenden (weil im Pool auch SSD Trim geht) und dort eben ein Dateisystem wählen, dass Dir die Verfügbarkeit erhöht, zB zfs in einen Mirror. In beiden Fällen, unRaid-Array/primary Storage mit Parity oder Unraid-Pool/Secondary Storage wären zwei Disks notwendig.
  14. ...das willst Du jetzt vielleicht nicht hören, aber mMn wäre es das Beste - bei dem geringen Platzbedarf - die SSDs nochmal "durchzutauschen", sodas Du zwei identische hast. Am besten natürlich SSDs mit eigenem RAM+SLC Cache...davon eben 2 Stück. Diese beiden dann als secondary Storage in einem zfs-Mirror und als Array/primary Storage (eine Disk *muss* im Array sein, sonst startet unraid nicht) einfach einen beliebigen USB-Stick (*nicht* den USB-Boot/Unraid-Stick).
  15. Wieso über die SMB-Extra Config? Ist SMB nicht "dumm"? Im Zweifel den unraid-Pool identisch (Pfad und Name ist wichtig) mit einer anderen DIsk erstellen, die SMB-Shares in unraid konfigurieren und dann den "dummy" unRaid-Pool gegen den "richtigen" Unraid-Pool (mit "deinem" zpool) tauschen....könnte funktionieren, hab ich aber noch nicht gemacht Nein, sollte nicht so sein. Warum es nicht geht kann Dir nur ein unraid ZFS-Guru sagen. Mein best Guess wäre, ob Dein alter zfs-pool nicht auf der neuesten zfs-Version aufgebaut ist ... ein beherztes "zfs-upgrade" kann das klären. ...ich würde dann genau an dieser Fundstelle mal nachfragen Ansonsten bleibt noch den unraid einfach mal ein paar Jahre durchlaufen zulassen 🤣...machen Viele so.
×
×
  • Create New...