[Sammelthread] Proxmox Stammtisch

(Nicht sicher, ob das hierher gehört oder in den ZFS-Faden.)

Habe 2x Exos X18 16 GB und 2x PM883/893 480 GB (+ MC12-LE0, 5600X, 64 GB ECC, sollt aber egal sein). Daraus soll ein Backupserver auf Proxmox-Basis werden. Proxmox hauptsächlich deshalb, weil's im Gegensatz zu einem nackerten Debian stable gleich mit ZFS daherkommt, und ohne jedes Theater davon bootet. Ganz abgesehen davon hasse ich bare metal backup / restore, VMs sind da einfach komfortabler. Und wenn's einmal sein muss kann ich auch die ein oder andere VM (container), die nichts mit Backup zu tun hat, auf dem Ding laufen lassen, bis das primäre System wieder funzt.

Die Kiste soll ZFS backups von den (File-)Servern via zfs receive, BTRFS backups von den Desktops via btrfs receive (notgedrungen via BTRFS-on-ZVOL), PVE backups via PBS (in einer VM), und mehr oder minder konventionelle Dateibackups (schaut momentan nach restic aus) annehmen, das wichtigste Zeug auch noch zu Hetzner verfrachten (schaut auch nach restic aus), und die Daten ansonsten sicher begraben, bis ich sie hoffentlich nie brauch.
Das Ding fährt in der Nacht hoch, pullt Backups von allem was wach ist, und schläft wieder ein (oder fährt ganz runter).

Frage 1 – Pool-Setup

N.B. Alle vdevs mirrored.
  1. Dem Proxmox-Installer den Großteil der zwei SSDs für den RPOOL lassen, Rest special vdev für einen Pool aus den beiden Platten.
    Contra: Lange hieß es, dass auf dem root pool wirklich nur das System liegen sollte, u. a. weil der gerade unter Linux Einschränkungen unterliege. Abgesehen davon möchte ich den Platz auf den SSDs nicht nur für Proxmox und seine VMs nutzen; k. A., ob man auf einem pool, den Proxmox als "seinen" Systempool ansieht, gefahrlos andere Datasets/ZVOLs anlegen kann.
    oder
  2. Noch kleinerer RPOOL (per Installer), dahinter ein kleiner, manuell angelegter SSD-Pool, dahinter special vdev für den HDD-Pool. Kann ja immer noch ein Dataset auf dem SSD-Pool anlegen und in Proxmox als Datastore einbinden.
    Contra: Komplexer, und man müsste es schaffen, den Platzbedarf der drei Partitionen richtig abzuschätzen.
Frage 2 – BTRFS-on-ZVOL
  • Mir ist klar, dass das weit jenseits von ideal ist – irgendwelche Tipps, wie man den Schaden zumindest minimieren kann? So schnell muss es ja nicht sein, ist ja nur für Backups, aber einserseits möcht ich keine Performance liegen lassen, andererseits ist die write amplification für die SSDs auch nicht gerade lebensverlängernd.
  • Das Einzige, was mir ausser Filesystemtuning auf ZFS- und BTRFS-Seite eingefallen ist, ist die Anzahl der Snapshots klein zu halten und "alte" Snapshots in ein restic repo zu verfrachten. So ist die Versionierung noch etwas länger möglich ohne BTRFS mit hunderten Snapshots zu belasten (was es schon bare metal gar nicht mag).
Frage 3 – ZFS-Replikation
  • Was nimmt man heutzutage als Frontend für zfs send/receive? PBS selbst kommt für PVE-fremde Datasets ja wohl nicht in Frage. Gut, ich hab meine alten Skripte, aber wenn's was bewährtes Fertiges gibt, nehm ich das gerne.
Frage 4 – PBS
  • Für den PBS wird ja dringend empfohlen, ihn auf SSDs laufen zu lassen – gilt das auch dann, wenn er nur von einem remote pullt? Hab nämlich Zweifel, dass der Platz auf den SSDs reicht, und für ruhende Daten isser mir auch zu schade.
  • Kann man da irgendwas optimieren? Z. B. Metadaten (der PBS-Backups) auf den SSD-Pool, Chunks auf den HDD-Pool?
Frage 5 – Sleep
  • Grundsätzlich sollte systemctl suspend normal funktionieren, gibt's irgendetwas zu beachten?
Frage 6 – Virtualise everything
  • Würdet ihr in dem Fall das, was es halt sonst noch so braucht (btrfs-tools, btrbk, restic, ...) auf dem Host installieren oder in Container? (PBS kommt fix in eine VM.)
So. Kommen sicher noch viel mehr Fragen, aber ich denke, fürs Erste wars das. Noch hab ich ja Zeit zum Planen, is noch nicht die ganze Hardware da. (Und richtig ans Eingemachte geht's eh erst, wenn der neue kugelsichere Backupserver steht und bespielt ist. Dann gibt's entweder Ceph oder zumindest einen 2+1 PVE-Cluster mit ZFS-Replikation.)

Jegliche Anregungen willkommen.
Beitrag automatisch zusammengeführt:

Harddisk ist eh suboptimal, SSDs kosten nichts mehr.

Also ich weiß nicht. Die Seagate Exos (günstigste ordentliche HDD lt. GH) gibt's ab ~€15/TB, SSDs fangen bei €95/TB an, wobei wir da von €700–800/Disk reden. Die Samsung PM883 1 TB liegt bei €114. Also immer noch gut das 7-fache. Natürlich kann man auch Consumer-SSDs nehmen, bei denen darf man dann wie ein Haftelmacher aufpassen, dass man nicht zu viel schreibt, und bei jeglichen sync writes steht das Ding dann. Und wehe es ist voll. Nein, HDDs haben durchaus noch eine Daseinsberechtigung, und nicht nur als Datengrab.

Wenn Firewall = OPNsense, dann go HA

Tell me more. Hat OPNsense eingebaute HA-Unterstützung, oder wie? Wenn das günstig realisierbar ist, wärs ein Grund, meine Eigenbaulösung aufzugeben.

andernfalls sind deine Datenbanken unter Umständen nach einem restore nicht konsistent.

Das sagen alle, also wird es schon stimmen, aber verstehen tu ich's nicht. So ein Backup im laufenden Betrieb ist auch nicht schlimmer als wenn der Kübel den Strom verliert. Sind halt die letzten paar Transaktionen nicht mehr drin, aber konsistent sollte die DB immer sein. Oder verwenden die Leut heutzutage nur noch non-ACID-Datenbanken?
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
N.B. Alle vdevs mirrored.
  1. Dem Proxmox-Installer den Großteil der zwei SSDs für den RPOOL lassen, Rest special vdev für einen Pool aus den beiden Platten.
    Contra: Lange hieß es, dass auf dem root pool wirklich nur das System liegen sollte, u. a. weil der gerade unter Linux Einschränkungen unterliege. Abgesehen davon möchte ich den Platz auf den SSDs nicht nur für Proxmox und seine VMs nutzen; k. A., ob man auf einem pool, den Proxmox als "seinen" Systempool ansieht, gefahrlos andere Datasets/ZVOLs anlegen kann.
ich hab meinem proxmox mit 2*2TB NVME einfach einen z mirror erstellen lassen bei install und ein paar MB frei gelassen als spare space

die sind eh overkill an I/O
 
@Weltherrscher
Sehr cool. 👍🏻 Bin gespannt, ob du alle CUDA Features in den VMs auch sauber ans Laufen bekommst. Keep us posted, please. ;-)
 
Kernel 6.8 läuft, aber weils Maxwells sind, bin ich auf Treiber 535.184 begrenzt.
CUDA will ich als nächstes mal mit Immich und / oder Nextcloud probieren.
Momentan muss ich zusehen, dass die Karte ins PL12 geht, aktuell hängt sie in PL8 fest, was 70 W mehr im Leerlauf sind. :fresse:
 
Hast du den 6.8er anpassen müssen oder läuft das ohne Anpassung out of the box?
 
Ja, dann so rum. Du musstest auf jeden Fall etwas patchen 😊 Das kann ich hier produktiv eher nicht machen. Dann bleibt es erstmal beim Kernel 6.5.
 
Wenn ihr neuere Karten als Pascal habt: der 550 ging ohne zu patchen mit dem 6.8er Kernel zu installieren.
Der hat aber keine Profile für die M60 gefunden (logisch, weil ja Support nur bis 535).

//Edith:
1729110273682.png
1729110379039.png

Wischtisch!
iommu von Intel auf virtio stellen, sonst gibts Fehler im Kernel der VM und nvidia-smi findet in der VM nix.
Alter.

//Edith2:
Aha.
Zwar vGPU, aber Maxwell ist nicht preemptive.
-> einzig das 8Q-Profil ist für CUDA verfügbar.
Damit kann die M60 genau ZWEI VMs mit CUDA betreiben (je eine pro GM204).
*NARF*
CUDA mit kleineren Profilen geht erst ab Pascal.

Jetzt fluppt zumindest mal Immich mit CUDA:
1729116406813.png
1729116445796.png
 
Zuletzt bearbeitet:
In dem Thread liest es sich am Ende aber aktuell so, als wäre RDMA / SMB Direct nicht aktiv. An die Performance beim Copy-Job kommt man ja auch ohne RDMA ran, interessant (und einfacher Test) ist aber, ob der Windows Taskmanager auf dem Client dabei Last auf der relevanten Nic zeigt (wenn ja -> oldschool Verbindung, wenn nein -> RDMA aktiv).

EDIT & Nachtrag: evtl. muss ich doch mal wieder eine längere Session im Keller planen...
 
Zuletzt bearbeitet:
Dummerweise gab es gerade mal wieder günstig bei Ebay eine Dual ConnectX-5… Mitte November kann ich dann mal wieder spielen und probiere mal weiter RDMA-Gedöns (und vielleicht auch endlich mal mit dem Switch…)…
 
Für Windows habe ich in napp-it cs Einstelloptionen für RDMA integriert.
Falls etwas fehlt oder mit Debian/Proxmox ähnliches sinnvoll ist, kann ich ein entsprechendes Menü ergänzen damit RDMA einfacher zu implementieren ist oder man den Status schneller sieht.

1729721201101.png
 
Ja, eh. Die Frage is, wie man das am besten minimieren kann. Anderes FS spielts nicht, die Clients verwenden BTRFS und bleiben dabei. Und grad wenn man btrbk eh schon für versioning auf den Clients nutzt, sind die Snapshots fürs Backup sowieso vorhanden. Geht einfach nix über send/receive, wenn man möglichst schnell und unkompliziert Backups Richtung Server loswerden will.

Gut, BTRFS-seitig kann man eh nix tunen. Wobei evtl. compression dort besser funktioniert als auf der ZFS-Seite, weil sie Extent- und nicht Block-basiert ist. Dann muss man volblocksize nicht raufdrehen, zumindest nicht deshalb. Dedup detto. Aber z. B. k. A., in welchen Größeneinheiten ein btrfs receive typischerweise schreibt, und was das für Rückschlüsse auf die ideale volblocksize zuläßt. Auf der ZFS-Seite gibt's dafür 100000 tunables, wobei da ja die drunterliegende Hardware (HDD pool mit SSD special, sogar mit PLP) auch noch was mitzureden hat.

V.a., das Ding hat 64GB RAM, das kann prinzipiell den ganzen Snapshot cachen, bevor es irgendetwas tatsächlich schreiben muss. In der Theorie wäre die Flexibilität, die writes dann in einer Form rauszuhauen, dass das nicht allzu weh tut, da.

Na, wenn's keine Erfahrungswerte gibt, werd ich halt testen müssen.
 
blöde frage, aber wie komme ich auf meinen AdGuard Home Web GUI? Habe alle möglichen Kombinationen von IPs mit Ports ausprobiert...keiner geht =(

Thema SATA HDD und OpenMediaVault:
Egal was ich mache, aber meine HDD taucht ums verrecken nicht unter pve/Disks/LVM/ auf....ich Formatiere sie unter Disks und mache das Initialisieren aber nichts geschieht....

Edit:
Habe jetzt OpenMediaVault als VM installiert und geschafft die HDD einzubinden. Nun wollte ich die vollen 18TB an die VM hängen, bekomme aber bei mehr als 11TB immer eine Fehlermeldung?
 
Zuletzt bearbeitet:
HowTo use Proxmox als ZFS NAS und VM Server
 
in einigen deutschen Firmen/öffentlichen Diensten geht jetzt endlich mal das Thema "digitale Souveränität" rum, so das ich jetzt endlich die Genehmigung erhalten habe, meine Systeme anstatt von vmware auf hyper-V, nun doch auf Proxmox schwenken darf. War ein harter Kampf, da die restlichen Kollegen alle seit Jahren HyperV verwenden (mehr schlecht als recht) und ich den Ruf als ewig Gestriger weg hatte, obwohl meine Systeme die Zuverlässigsten und Unkompliziertesten waren. Aber Millionen Fliegen können nicht irren.....
Eine kleine Live-Präsentation eines vor den Augen des Chefs schnell zusammengeszimmerten Proxmox-Clusters inkl. totales Disasterrecovery hat aber überzeugt.

Nun mein Problem: Hardware sind alles HP-Server G8 bis G10 mit internen meist P420i und zweitem nachgerüsteten P420 HP Raidcontrollern.
Bisher habe ich nichts gefunden, das ich diese in einen HBA-Mode umflashen oder umstellen kann. Kennt da jemand was?
Die nachgerüsteten Kontroller könnte ich ggf durch HBAs im IT-Mode ersetzen, die internen kann ich wohl nicht ersetzen, da keine PCIe-Steckplätze mehr frei.
Wäre Schade, wenn dieses Projekt nun an den HBAs scheitern sollte.
Wer hätte Ideen oder Infos für mich?
 
Wenn man ZFS haben möchte, was ja mit Proxmox absolut Sinn macht, so muss man lediglich zwei Sachen beachten.

1. niemals ein Raid ausserhalb von ZFS machen (atomic write/ write hole Problematik)
2. kein Cache auf einem Controller nutzen sondern immer nur ZFS read/write cache.

IT Firmware muss nicht sein, ein HBA Mode bei dem Platten direkt ans OS weitergereicht werden ist perfekt, zur Not geht auch ein Raid-0 Mode einzelner Platten. Schön wenn smartctl noch funktioniert.
 
Nun mein Problem: Hardware sind alles HP-Server G8 bis G10 mit internen meist P420i und zweitem nachgerüsteten P420 HP Raidcontrollern.
Bisher habe ich nichts gefunden, das ich diese in einen HBA-Mode umflashen oder umstellen kann. Kennt da jemand was?

probier mal folgendes - hab ich selber noch nie probiert:

 
Dank für den Link, aber für Business-Umfeld ist mir das doch zu sehr mit der heißen Nadel gestrickt.
Ich schaue mal, ob ich nicht in den einen oder anderen Host nicht doch noch einen zweiten HBA unterbekomme oder ich verwende den internen P420 nur zum Booten und als Installationsmedium für den PVE selbst.
Die VM-Daten dann auf ZFS auf den anderen neuen HBA.
 
Das Hauptproblem mit ZFS ist das Cachemodul. Ist das nicht gesteckt und der Controller arbeitet auch ohne das Modul? Raid 5/6 Support will/braucht man ja eh nicht.
 
Dank für den Link, aber für Business-Umfeld ist mir das doch zu sehr mit der heißen Nadel gestrickt.
Ich schaue mal, ob ich nicht in den einen oder anderen Host nicht doch noch einen zweiten HBA unterbekomme oder ich verwende den internen P420 nur zum Booten und als Installationsmedium für den PVE selbst.
Die VM-Daten dann auf ZFS auf den anderen neuen HBA.

Die gen8 sind gut 10-12 Jahre alt, da würde ich mir darüber keine großen Gedanken machen.

Du kannst ja das OS ggf auch vom internen Sata booten. Es ist auch eine unschöne bastelei, aber die Hardware ist halt auch nicht mehr frisch.
 
Wer hat viel Ahnung von Proxmox, RDMA und (Linux / Mellanox) Networking und noch mehr Geduld als Ahnung? :d

Ich versuche (mal wieder) mein Glück, RDMA für Arme (mich) nutzbar zu machen, und zwar vor allem mit Windows auf der Client-Seite. Klassischerweise funktioniert das am einfachsten mit Windows auch auf der Server-Seite, allerdings wissen wir alle, dass Microsoft (auch) da lizenzmäßig nicht mehr kostenlos unterwegs ist, seitdem insbesondere der Hyper-V Server eingestellt wurde.

Mein Ziel: Zugriff auf SMB-Shares auf einem Proxmox Server per SMB Direct (RDMA).

Wo stehe ich: Hardware-Test mit reiner Windows-Umgebung erfolgreich (siehe hier). ConnectX-5 im "Server" (Threadripper 3960X) und ConnectX-4 im "Client" (Intel 13900KS mit Windows 11 Pro for Workstations).

Nur einfach mal Proxmox und ksmbd installieren führt schonmal NICHT zum Ziel. ;)

Was habe ich bisher gemacht:

1. quick & dirty ksmbd.conf für guest-write access sieht so aus (insb. server multi channel support = yes gesetzt):
Code:
; see ksmbd.conf(5) for details

[global]
        ; global section parameters
        unix charset =UTF-8
        workgroup = WORKGROUP
        server string = SMB-Proxmox
        guest account = nobody
        create mask = 0777
        directory mask = 0777
        browsable = yes
        map to guest = bad user

        ;bind interfaces only = no
        ;deadtime = 0
        ;guest account = nobody
        ;interfaces =
        ;ipc timeout = 0
        ;kerberos keytab file =
        ;       kerberos service name =
        ;map to guest = never
        max active sessions = 1024
        max open files = 10000
        netbios name = KSMBD SERVER
        ;restrict anonymous = 0
        ;:root directory =

        server max protocol = SMB3_11
        server min protocol = SMB2_10
        server multi channel support = yes
        server signing = disabled
        ;server string = SMB SERVER
        share:fake_fscaps = 64
        smb2 leases = no
        smb2 max credits = 8192
        smb2 max read = 4MB
        smb2 max trans = 1MB
        smb2 max write = 4MB
        smb3 encryption = no
        smbd max io size = 8MB
        tcp port = 445
        ;workgroup = WORKGROUP
        max connections = 128
        aio max threads = 100
        aio read size = 1
        aio write size = 1
        ; share parameters for all sections

[example]
        ; share parameter overrides for `example' share
        writeable = yes
        public = yes
        guest ok = yes
        path = /tmp
(END)


2. Windows-Client-Seite geprüft, zeigt auch weiterhin RMDA Capable an:
1730475792312.png

3. Um tiefer einzusteigen erst einmal Mellanox OFED (bzw. jetzt "DOCA-OFED") installiert. Das war schon ein gewisser Krampf für so'n Dau wie mich.
Das x86 Deb-Package für 12.5 von der Nvidia-Dowloadseite installiert per
Code:
dpkg -i doca-host_2.8.0-204000-24.07-debian125_amd64.deb
apt-get update
apt install -y doca-all mlnx-fw-updater


Dann ließ sich aber leider "/etc/init.d/openibd restart" nicht ausführen (weil ksmbd noch irgendein Modul nutzt, auch wenn man ksmbd gestoppt hat). Außerdem meldet "mst restart" einen lustigen Fehler, weil es das Modul mst_pciconfig nicht findet. So weit, so Kacke.

Nvidia sagt zwar, dass alles tutti sei, wenn - wie bei mir - "If the build directory exists in under /lib/modules/$(uname -r)/build, then the kernel headers are installed.", aber wer weiß / glaubt das schon?

Kernel-Header gibt's aber nicht so ohne weiteres. Also erstmal das no-Subscription repository konfiguriert und die Enterprise-Dinger rausgeworfen.

Dann die Kernel Headers mit "apt install proxmox-default-headers" installiert.

Dann also den Doca-Mist wieder deinstalliert (immer danke für die Anleitungen, nvidia!) und neu installiert.

Keine Besserung. Mal rebooten?

Na siehe da, jetzt läuft auch "mst restart" und netterweise auch "/etc/init.d/openibd restart".

Dummerweise funzten nun das 100Gbit-Netz nicht mehr (IP-Adressen nicht mehr per ping erreichbar).... was sich aber mit Löschen und Neuanlegen der zugehörigen Linux-Bridge (vmbr1) beheben ließ.

Aktuell bekomme ich allerdings ksmbd nicht mehr zum Laufen. Wird wohl auf eine Proxmox-Neuinstallation hinauslaufen. Ich liebe es. :d
 
Ok. Neue Installation, neuer Versuch.

Was habe ich nach fresh Install gemacht:

1. no-subscription repository aktiviert
2. apt update
3. apt upgrade
4. apt install ksmbd-tools
5. modprobe ksmbd
6. /etc/ksmbd/ksmbd.conf angelegt
7. apt install -y infiniband-diags ibutils rdma-core rdmacm-utils mstflint

Immerhin funktioniert ksmbd (noch).

Aber irgendwo ist der Wurm drin. rping zum Beispiel findet kein RDMA Device. lsmod | grep rdma zeigt aber immerhin was:
Code:
root@pve:/etc/init.d# lsmod | grep rdma
rpcrdma               389120  0
sunrpc                778240  2 rpcrdma
rdma_ucm               32768  0
irdma                 417792  0
ice                  1081344  1 irdma
rdma_cm               143360  4 rpcrdma,ib_iser,ksmbd,rdma_ucm
iw_cm                  57344  1 rdma_cm
ib_cm                 143360  2 rdma_cm,ib_ipoib
ib_uverbs             180224  3 irdma,rdma_ucm,mlx5_ib
ib_core               483328  12 rdma_cm,ib_ipoib,rpcrdma,iw_cm,ib_iser,ib_umad,irdma,ksmbd,rdma_ucm,ib_uverbs,mlx5_ib,ib_cm
i40e                  573440  1 irdma

Statt der DOCA-Version hab ich es diesmal mit MLNX_OFED versucht. Immerhin hab ich mir bisher ksmbd noch nicht zerschossen, aber ich bekomm' die MLNX Treiber nicht gescheit installiert. Scheitert witzigerweise anscheinend beim Uninstall alter ofed-Treiber.

Randbemerkung: der Mellanox-Installer behauptet, es liefe Debian 12.7 (nicht 12.5).

Mir scheint insgesamt, es gibt einen Konflikt bzw. nicht auflösbare Abhängigkeiten zwischen Proxmox und den Mellanox-Geschichten. Auch der DOCA-Treiber will, dass man die alten Versionen / Pakete deinstalliert, unter anderem "proxmox-ve", was natürlich gewisse Panik auslöst:
Code:
W: (pve-apt-hook) !! WARNING !!
W: (pve-apt-hook) You are attempting to remove the meta-package 'proxmox-ve'!
W: (pve-apt-hook)
W: (pve-apt-hook) If you really want to permanently remove 'proxmox-ve' from your system, run the following command
W: (pve-apt-hook)       touch '/please-remove-proxmox-ve'
W: (pve-apt-hook) run apt purge proxmox-ve to remove the meta-package
W: (pve-apt-hook) and repeat your apt invocation.
W: (pve-apt-hook)
W: (pve-apt-hook) If you are unsure why 'proxmox-ve' would be removed, please verify
W: (pve-apt-hook)       - your APT repository settings
W: (pve-apt-hook)       - that you are using 'apt full-upgrade' to upgrade your system
E: Sub-process /usr/share/proxmox-ve/pve-apt-hook returned an error code (1)
E: Failure running script /usr/share/proxmox-ve/pve-apt-hook

Also: entweder ksmbd mit rdma ohne die Mellanox-Tools oder rdma ohne Proxmox weiter versuchen... da ich bestimmt bei diversen Brechstangen-Versuchen (--force -f ...) irgendwas zerschossen habe, muss ich eh neu installieren. Vielleicht doch mal nen nacktes Debian...?

EDIT & Nachtrag: erstmal die Schnauze voll von Proxmox. Muss mal gucken, ob ich mit Debian oder gleich mit Ubuntu weitermache.
 
Zuletzt bearbeitet:
Du müsstest mal ein komplettes Log posten, dann kann man ggf was dazu beitragen.


"All Mellanox, OEM, OFED, or Distribution IB packages will be removed."

Ich vermute mal ksmbd wird mit dem Nvidia Kram so oder so keine Freude haben.
 
Was ein K(r)ampf.

Hab nach langem Gefrickel nun Debian mit den richtigen NICs / IPs laufen und auch die OFED-Treiber (DOCA) installiert.

Teilerfolg: Windows und Linux sprechen RDMA miteinander - mit Linux:rping<-->Windows:nd_rping

Server (Debian):
Code:
rping -v -s -a 10.100.1.1

Client (Win11):
Code:
nd_rping -v -c -a 10.100.1.1

Ergibt einen HAUFEN (hier nur ein Auszug):
Code:
ping data: rdma-ping-6068: efghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXY
ping data: rdma-ping-6069: fghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ
ping data: rdma-ping-6070: ghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[
ping data: rdma-ping-6071: hijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[\
ping data: rdma-ping-6072: ijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[\]
ping data: rdma-ping-6073: jklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^
ping data: rdma-ping-6074: klmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_
ping data: rdma-ping-6075: lmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`
ping data: rdma-ping-6076: mnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`a
ping data: rdma-ping-6077: nopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`ab
ping data: rdma-ping-6078: opqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`abcd
^C

Ich bekomme aber ums Verrecken keine Verbindung über ib_send_bw & Co. hin.

Habe allerdings im Netz irgendwo bei NVIDIA auch die Aussage gesehen, dass rping das einzige Tool für Tests zwischen Linux und Windows sei. ib_send_bw läuft jedenfalls zwischen zwei Shells auf ein und derselben Linuxkiste und umgekehrt auch nd_send_bw in zwei CMDs auf dem Windows-Client.

@VirtuGuy: Sorry für die doofe Frage, wo finde ich denn das „komplette log“?
 
ich meinte das komplette Log von der Treiberinstallation.

bezüglich ib_send, hier sollte ja auch irgendein Output kommen. Ich wette fast du läufst in ein Speicherlimit (/etc/security/limits.conf).
 
Zuletzt bearbeitet:
Ah ok. Schaue ich mir auch mal an. Die Install-Logs hab ich aktuell nicht mehr, da ich zuletzt mit nativ Debian unterwegs war.

Momentan probiere ich mein Glück mal mit Ubuntu, da komm ich mit der Konfiguration tendenziell etwas besser klar und da ist von den ksmbd-Tools immerhin auch die aktuelle Release-Version dabei. Übrigens erstmal ohne die manuell installierten Mellanox Treiber. Mal schauen.

EDIT & Nachtrag:

Unter Ubuntu 24.10 (24.04 lässt sich ksmbd-tools nicht ootb als Paket installieren) sieht es auf den ersten Blick besser aus. Keine großen Fehler, alle Tools wie z.B. ibv_devinfo laufen auch ohne Mellanox Treiber und selbst dmesg meldet, dass ksmbd irgendwelche ib-devices findet und zeigt erstmals was von wegen smb_direct.

Der Windows Taskmanager zeigt aber leider immer noch Last bei nem Copy-Job auf eine ksmbd-Freigabe. :(

Hab mal hier nen Post dazu drangehängt. Vielleicht hat ja der Entwickler ne Idee, was ich noch probieren kann...
 
Zuletzt bearbeitet:
signierung/verschlüsselung hast du am Client deaktiviert? Eigentlich sollte der Client es selber abdrehen weil ksmbd es nicht kann, aber who knows.
 
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