[Sammelthread] Proxmox Stammtisch

Der Klassiker wäre, dass da ein Namensschema für die Netzwerkinterfaces verwendet wird, sodass sich die Namen ändern, wenn sich an den PCI-Karten was ändert; Ergebnis: Netzwerk kommt nicht mehr hoch.
In dem Fall: In der alten Konfiguration das Namensschema auf etwas Brauchbares pinnen (https://pve.proxmox.com/wiki/Network_Configuration#_naming_conventions), dann umstecken.
Danke für den Hinweis, ich konnte das Problem mit der .link Datei und angepasster "interfaces" lösen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Ich hab ja mal auf ner Testinstallation angefangen, bei Proxmox mit ksmbd rum zu testen.

Also fluggs ksmbd-tools installiert, user dafür angelegt, ein ZFS Dateisystem angelegt, mountpoint vergeben und ein ksmbd-share auf das Verzeichnis mit dem Mountpoint gesetzt.
Und nun versteh ichs nicht mehr. Ich kann vom Windows Client aus in dieses Share reinschreiben, es wird aber nichts gelistet. Leeres Directory. Schau ich direkt am Server, sind die Dateien
aber in dem ZFS Dateisystem gelandet. Was mach ich falsch?

Mit Samba funktioniert das Problemfrei, der ksmbd scheint aber als Directory das Mount-Verzeichnis an den Client auszugeben, nicht das ZFS-Dateisystem. Daher leer.

ksmbd.conf:

Code:
[global]
unix charset = UTF-8
workgroup = DAHEIM
server string = SMB-Server
guest account = nobody
create mask = 0775
directory mask = 0755
browseable = yes
map to guest = bad user
usershare allow guests = yes

# optionally add shares

[share_example]
guest ok = yes
path = /mnt
writeable = yes

[share_example2]
guest ok = yes
path = /tank
writeable = yes
 
Klappts denn bei dem sample-Share?

Füg mal ein „browseable = yes“ bei den Shares hinzu?
 
Nope bei beiden.
Schreiben erfolgt immer ins ZFS-Filesystem, lese/directory aus dem "Gast"-Verzeichnis des Mountpoints.

ksmbd scheint hier beim Lesen nicht zu erkennen, dass hier was gemounted wird und es kein "echtes" Verzeichnis ist.
Ist übrigens auch so, wenn ich einen zweiten Pool anlege und versuche da zuzugreifen. Gleiches Problem.
 
Wenn du Gäste mal deaktivierst und nur authentifizierte User drauf lässt?

//Edith:
Die "map to guest" Einträge mal löschen hilft auch oft, scheint verbuggt zu sein...
 
Zuletzt bearbeitet:
Blöde Frage, aber wie richtet man eigentlich einen Remote Zugang zu einer virtuellen Maschine für Spice ein?

In Proxmox selbst bekomm ich ja ein .vv File zur einmaligen Verwendung.
Beim TrueNAS V-Host ist es so, dass ich selbst ein statisches .vv File erstellen kann mit den Zugangsdaten drin (plain text, wäre für meinen Zweck aber in Ordnung).

Wie macht man das "richtig"?
Könnt ihr mir ein Stichwort nennen, nachdem ich suchen kann und fündig werde?
 
Beitrag automatisch zusammengeführt:

Solange dus unter Linux machen willst, gibts nen Bash-Skript für...
 
Zuletzt bearbeitet:
ich würde gerne meine Proxmox Installation umziehen.

Ist es möglich die beiden M.2's mit der Installation (die VM's liegen auch darauf) auf andere Hardware (Board,CPU,...) umzubauen?

Sauberer wird es vermutlich sein, alles aufs NAS zu sichern und nach der neu Installation auf dem neuen System wieder zurück zu spielen.
 
ich würde gerne meine Proxmox Installation umziehen.
Ist es möglich die beiden M.2's mit der Installation (die VM's liegen auch darauf) auf andere Hardware (Board,CPU,...) umzubauen?
Sauberer wird es vermutlich sein, alles aufs NAS zu sichern und nach der neu Installation auf dem neuen System wieder zurück zu spielen.

 
Hatte jemand sowas schon mal?
Auf einer Maschine ranzt Proxmox jetzt immer nach einiger Zeit ab.
Screenshot From 2024-12-13 00-25-59.png
 
SSD's für Proxmox!?

Mein derzeitiger Stand der Dinge:
"Eigenbau-Server (TrueNAS scale / derzeit bare metal)": Gigabyte C246M-WU4, Intel Xeon E-2226G, 4x16GB Kingston (KSM26ES8/16ME) ECC-Ram, Intel i350-F2 (LWL), Intel DC 3700 200GB (OS), Dell H330 Controller (LSI3008 "it mode") + 2x Toshiba Enterprise MG07ACA 12TB + 2x Intel D3-S4510 1,92TB

Auf der 200GB Intel DC SSD läuft derzeit TrueNAS scale "bare metal" - ich möchte aber künftig auf Proxmox umsteigen und dort dann TrueNAS als VM laufen lassen und noch ein paar andere Dinge.


Ich würde gerne 2 SSD's gespiegelt (ZFS) betreiben, wo dann Proxmox + die VM's/Container drauf laufen sollen - bin mir aber nicht ganz sicher, was hier am Sinnvollsten ist!?
Hab mir vor einiger Zeit mal 2 Stk. Samsung PM893 480GB Sata SSD's auf Lager gelegt - bin aber irgendwie am überlegen, ob ich die wieder verkaufe und mir 2 M2-SSD's besorge!?

Wie "nötig" ist denn bei diesen SSD's dann PLP?
Der Server hängt an einer ordentlichen APC-USV.

Müssen es also "zwingend" Server-SSD's sein, oder könnte man auch z.B. folgende nehmen!?

  • WD Red SN700 NAS 1TB
  • Samsung 980 1TB

"Consumer-SSD's" bei TrueNAS ist keine gute Idee - habe ich mal ein paar Monate betrieben - die haben da schon ordentlich gelitten - wie verhält sich das bei Proxmox?


Vielen Dank im Voraus!


LG
 
SSD's für Proxmox!?

Mein derzeitiger Stand der Dinge:


Auf der 200GB Intel DC SSD läuft derzeit TrueNAS scale "bare metal" - ich möchte aber künftig auf Proxmox umsteigen und dort dann TrueNAS als VM laufen lassen und noch ein paar andere Dinge.


Ich würde gerne 2 SSD's gespiegelt (ZFS) betreiben, wo dann Proxmox + die VM's/Container drauf laufen sollen - bin mir aber nicht ganz sicher, was hier am Sinnvollsten ist!?
Hab mir vor einiger Zeit mal 2 Stk. Samsung PM893 480GB Sata SSD's auf Lager gelegt - bin aber irgendwie am überlegen, ob ich die wieder verkaufe und mir 2 M2-SSD's besorge!?

bringt auf jeden Fall Performance

Wie "nötig" ist denn bei diesen SSD's dann PLP?
Der Server hängt an einer ordentlichen APC-USV.

was heißt schon nötig.
Für VM Storage sollte man auf jeden Fall sync aktivieren. Auch ohne plp ist im Mirror wegen der Redundanz ein gewisser Schutz der ZIL Daten gegeben. Für ein single Slog ohne Mirror wäre es ein NoGo.
Müssen es also "zwingend" Server-SSD's sein, oder könnte man auch z.B. folgende nehmen!?

  • WD Red SN700 NAS 1TB
  • Samsung 980 1TB

Desktop SSD sind deutlich schlechter bei steady write und mixed read/write
ZFS erzeugt eine deutlich höhere Schreiblast als "alte" Dateisysteme. Liegt an Copy on Write da dabei Daten nicht geändert werden sondern immer komplette Datenblöcke neu geschrieben werden. In einer großen Textdatei bedeutet das Ändern von "Haus" in "Maus" dann 1M Daten für 1 Byte Änderung bei recsize=1M.
Mit aktiviertem Sync wird jede Schreibaktion zweimal ausgeführt, einmal als Log, einmal als normales Write über den Schreibcache.

"Consumer-SSD's" bei TrueNAS ist keine gute Idee - habe ich mal ein paar Monate betrieben - die haben da schon ordentlich gelitten - wie verhält sich das bei Proxmox

Warum sollte das anders ein.
TN=Debian + ZFS
Proxmos= dasselbe Debian mit demselben ZFS
 
Hm, die Auswahl an M2 SSDs mit PLP ist ja ziemlich überschaubar - zusätzlich dann noch der sehr hohe Preis.

Entweder nutze ich doch die Sata-SSDs mit PLP, oder ich versuche es mit „normalen/günstigen“ M2-SSDs (gespiegelt) und schaue mal wie lange sie halten, bzw. rausche sie halt nach ein paar Jahren mal?!
 
@hs_warez

Ich habe noch 3x m2 SSD m2 mit echtem PLP günstig abzugeben:

Micron 7300 pro - 960GB
Model: MTFDHBA960TDF
Formfaktor: m2 / NVMe 2280

Pro Stück 80 inkl. DHP Paketversand oder alle 3 für 225 inkl. Paket Versand.
 
Kann es sein, dass Proxmox ne Bitch ist, selbst wenn man nur bei einem Solo-Host die IP-Adresse ändert? Ich hatte eine zweite IP vergeben auf einer weitere Bridge, auch das Gateway dahin geändert, welches ich für meine Verbindung gar nicht brauche , die alte IP bestand noch. Ich war mit dem Ergebnis nicht zufrieden und hab die Schritte genauso rückabgewickelt, wie ich sie vorgenommen hatte, dennoch war das Mist-Ding nicht mehr erreichbar. Und so was ist mir nun schon das zweite mal passiert.
Da Proxmox bei mir selber ne VM ist, war der Drops schnell gelutscht, dennoch... 😤
 
Datacenter Manager im Arbeit...


 
Liebes Froum, es stellen sich mir momentan 2 Fragen, die ich leider nicht ausreichend selbst beantworten kann...

1) Netzwerk für VMs:
Wenn ich jetzt ein TrueNAS als VM laufen lasse (ja, ich weiss, man kanns auch direkt machen), und dort eine gute Netzwerkanbindung haben will (also eine extra NIC, erstmal 2.5G, später 10G).
Muss ich die NIC dann per PCIe Passthrough der VM geben, oder reichts ne virtuelle NIC irgendwie per Bridge (hab mir das mit mehreren NICs noch nicht angesehen) zu machen?
Tut sich da performancemäßig irgendwas (relevantes)? Nicht nur bezüglich sequentiell, sondern auch bezügl. Latenz. Die Frage ist jetzt im "praktischen" Rahmen (mit "normalo" SMB) gesehen und nicht akademisch/theoretisch...

2) VM-Speicherplatz / Write-Amplification:
Wenn ich VMs anlege in dem thin-LVM, gebe ich ihnen dort einfach eine gewisse (maximal-) Größe.
Das kann ich dann natürlich verwenden, wie ich will, also frei mit der Wahl des Filesystems.
=> Was ich leider nicht verstehe ist, ob das nun "in" einem ZFS liegt, oder nicht... Vermutlich schon irgendwie, oder? Sonst wäre ja kein ZFS MIrror über das ganze möglich... (nebenfrage, wirkt da dann ein ARC Cache?).
Das heisst also, ich bin von der Write-Amplification her allgemein eher "ungünstig" unterwegs, selbst wenn ich ein XFS oder EXT4 in der VM mache, noch ungünstiger, wenn ich ein BTRFS oder ZFS drin verwende...
Oder ist das nur ein LVM-Raid-1 wo ein ZFS auf die Proxmox-Partition kommt?

Was für Alternativen hätte ich? Wie macht man das, um möglichst zweckmäßig unterwegs zu sein?
Snapshotting ist wsl. gar nicht sooo das große Thema, meine (die meisten) VMs sind nicht so wertvoll, die sind eher experimentell, stabil muss hauptsächlich der Filer sein.

Geplant wäre ein Mirror (auf welche Art auch immer) aus 2x 2tb KC3000... wsl. per PCIe 3.0x1 angebunden (evtl. ein ZIL/SLOG auf ner 7400pro PLP, wenns Sinn macht) (Home-Hardware halt...)... so schlecht sind die ja nicht, bissl was halten die schon aus, und so viel mach ich auch nicht drauf... richtige Enterprise-SSDs sind einfach kein Thema.

Proxmox OS und VM Speicher selbst wollte ich eigentlich nicht trennen... wäre zwar grundsätzlich denkbar (Proxmox auf SATA SSD), aber wiederum eine Mehrausgabe und komplizierter...



Könnt ihr mir da etwas Licht ins Dunkle bringen?
 
Zu 1. Ich würde ne Bridge nehmen, weil "einfacher". Zumindest, wenn man die Hardware mal wechselt. Was ich mir an deiner Stelle aber überlegen würde, ob Du auch VMs hast, die performant auf TrueNAS zugreifen sollen. Dann würde ich das Ganze vermutlich anders gestalten, denn aktuell scheint alles durch einen physischen Switch zu müssen, selbst VMs auf dem selben Host.
 
Wenn man Hardware wie eine Netzwerkkarte per Software emuliert, kann das nicht so schnell sein wie echte Hardware. Es gibt Unterschiede in der Emulation was die Effizienz, CPU Last oder Latenz angeht. Von ESXi mit der hochoptimierten vmxnet3 kenne ich es so, dass bei entsprechend potenter Hardware mehrere GBit/s problemlos gehen, 10 Gbit/s nicht erreicht werden und darüber ohne Passthrough garnichts geht.

Wenn man ZFS für Storage nutzt, so sorgen Copy on Write und das doppelte Schreiben bei sync für write amplification. Da ist es egal ob man NFS, SMB, iscsi nimmt, direkt im OS darauf zugreift oder darauf VMs ablegt. Copy on Write ist Vorraussetzung für ein crash resistentes Dateisystem und sync sorgt dafür dass beim Schreiben keine bestätigten Writes verlorengehen (=korrupte VM). Beides will man nicht missen so nimmt man write amplification gerne in Kauf, auch wenn eine VM mit ZFS auf darunterliegendem ZFS das zumindest für CoW verdoppelt. Man kauft halt eine SSD/NVMe die mit dem use case in der angedachten Nutzungszeit klar kommt oder ersetzt die halt wenn nötig.

Arc Cache gehört zu ZFS und jedes OS mit ZFS hat einen. Bei ZFS on ZFS kann man überlegen ob man den eventuell in einer VM ausschaltet. Wahrscheinlich ist es aber so dass das gar keine größere Relevanz auf Performance und Resourcenbedarf hat. Also einfach alles lassen wie es ist: Keep it simple. Besser nichts verstellen als falsch verstellen..
 
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