[Sammelthread] Proxmox Stammtisch

Ich fahr mein ZFS ja einfach verschlüsselt auf LUKS ;)

Warte aber sehnsüchtig auf die sich in Arbeit befindliche native ZFS Verschlüsselung...
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Man kann statt lvm auch zfs wählen bei der Installation


Gesendet von iPhone mit Tapatalk Pro
 
Genau, das habe ich auch gemacht (raid1) und die Daten als raidz1
 
Danke für eure Feedback. Wie ich das System mit ZFS einrichte ist schon klar, aber habe ich gegenüber dem vorgesehenen Standard (LVM) irgendwelche Nachteile?
Oder anders herum: Welche Vorteile hat LVM, dass Proxmox nicht gleich ZFS als Default anbietet?
 
Danke für eure Feedback. Wie ich das System mit ZFS einrichte ist schon klar, aber habe ich gegenüber dem vorgesehenen Standard (LVM) irgendwelche Nachteile?
Oder anders herum: Welche Vorteile hat LVM, dass Proxmox nicht gleich ZFS als Default anbietet?

evtl solltest du mal die Wiki und/oder Google zu LVM und ZFS befragen (hint)
 
muss ich beim "resize disk" eines mountpoints von einem LXC-Container irgendwas beachten?

Ich habe einen von 200GB auf 500 erweitert per webgui und die CT sagt mir bei df -h "500GB". Nextcloud sieht aber nur die 200GB. Auch nach einem Reboot..
 
Noch eine Frage zu Proxmox+LXC. Wird hier TRIM/discard nicht genutzt? Weil ich habe einen Mountpoint auf einem ZFS-Pool mit 80GB Daten, belegt aber 160GB? :confused:
 
TRIM hat mit der Speicherbelegung des Dateisystems nichts zu tun:
Der TRIM-Befehl ermöglicht es einem Betriebssystem, dem Speichermedium Solid-State-Drive (SSD) mitzuteilen, dass gelöschte oder anderweitig freigewordene Blöcke nicht mehr benutzt werden. Im Normalfall vermerkt das Betriebssystem nur in den Verwaltungsstrukturen des Dateisystems, dass die entsprechenden Bereiche wieder für neue Daten zur Verfügung stehen; der Controller des Solid-State-Laufwerks erhält diese Informationen in der Regel jedoch nicht.
Was zeigt dir ein zpool zfs list denn an?
 
Zuletzt bearbeitet:
Snapshots: Ja, aber nicht von der betreffenden CT.
TRIM bzw Discard wird nicht nur von SSDs genutzt. VMs kann man z.B. nur vor einem Überquellen der vDisks retten, indem man SCSI als Verbindung auswählt und dann manuell in der VM "fstrim -av" ausführt. So schaufelte ich da immer so einiges an GB frei. Was auch der Grund ist, warum ich auf LXC umgestiegen bin, da ich dachte, dass ZFS soetwas grundlegendes kann. Falsch gedacht :fresse:

Lösche ich vDisks, ISOs oder anderes, verändert sich der belegte Bereich in Proxmox (also doch TRIM?!), Lösche ich etwas aus meiner Nextcloud, dann bleibt der Mountpoint aber unverändert?!

Code:
# zfs list
NAME                           USED  AVAIL  REFER  MOUNTPOINT
rpool                          114G   111G    96K  /rpool
rpool/ROOT                    21.2G   111G    96K  /rpool/ROOT
rpool/ROOT/pve-1              21.2G   111G  21.2G  /
rpool/data                    83.9G   111G  1.16G  /rpool/data
rpool/data/subvol-103-disk-1  3.25G  11.7G  3.25G  /rpool/data/subvol-103-disk-1
rpool/data/subvol-103-disk-2    96K  10.0G    96K  /rpool/data/subvol-103-disk-2
rpool/data/subvol-103-disk-3    96K  20.0G    96K  /rpool/data/subvol-103-disk-3
rpool/data/subvol-104-disk-1   778M  9.24G   778M  /rpool/data/subvol-104-disk-1
rpool/data/subvol-107-disk-1  1.20G  8.80G  1.20G  /rpool/data/subvol-107-disk-1
rpool/data/subvol-110-disk-1  1.24G  19.1G   968M  /rpool/data/subvol-110-disk-1
rpool/data/subvol-110-disk-2   104K   100G    96K  /rpool/data/subvol-110-disk-2
rpool/data/subvol-111-disk-1  2.50G  12.5G  2.49G  /rpool/data/subvol-111-disk-1
rpool/data/subvol-114-disk-1   846M  9.17G   846M  /rpool/data/subvol-114-disk-1
rpool/data/subvol-115-disk-1   509M  14.5G   509M  /rpool/data/subvol-115-disk-1
rpool/data/subvol-117-disk-1   293M  7.71G   293M  /rpool/data/subvol-117-disk-1
rpool/data/subvol-119-disk-1   378M  14.6G   378M  /rpool/data/subvol-119-disk-1
rpool/data/vm-100-disk-1      7.21G   111G  7.21G  -
rpool/data/vm-102-disk-1      2.52G   111G  2.52G  -
rpool/data/vm-106-disk-2      35.7G   111G  35.7G  -
rpool/data/vm-108-disk-1      25.9G   111G  25.9G  -
rpool/data/vm-108-disk-2        96K   111G    96K  -
rpool/data/vm-112-disk-1       553M   111G   553M  -
rpool/swap                    8.50G   116G  3.83G  -
tank                           586G  1.18T   163G  /tank
tank/subvol-103-disk-1         128K   200G   128K  /tank/subvol-103-disk-1
tank/subvol-103-disk-2        11.1G   189G  11.1G  /tank/subvol-103-disk-2
tank/subvol-104-disk-1         160K   500G   160K  /tank/subvol-104-disk-1
tank/subvol-107-disk-1         128K   300G   128K  /tank/subvol-107-disk-1
tank/subvol-109-disk-3        2.58G  12.4G  2.58G  /tank/subvol-109-disk-3
tank/subvol-109-disk-4        63.8G   236G  63.8G  /tank/subvol-109-disk-4
[COLOR="#FF0000"]tank/subvol-111-disk-1         159G   341G   159G  /tank/subvol-111-disk-1[/COLOR]
tank/subvol-111-disk-2         128K   500G   128K  /tank/subvol-111-disk-2
tank/subvol-111-disk-3         128K   500G   128K  /tank/subvol-111-disk-3
tank/subvol-111-disk-4        2.02M   500G  2.02M  /tank/subvol-111-disk-4
tank/subvol-111-disk-5         128K   500G   128K  /tank/subvol-111-disk-5
tank/subvol-113-disk-1        2.57G  97.4G  2.57G  /tank/subvol-113-disk-1
tank/vm-100-disk-1            60.2G  1.18T  60.2G  -
tank/vm-101-disk-1            18.3G  1.18T  18.3G  -
tank/vm-101-disk-2            35.5G  1.18T  35.5G  -
tank/vm-105-disk-1            13.0G  1.18T  13.0G  -
tank/vm-106-disk-1            29.9G  1.18T  29.9G  -
tank/vm-108-disk-1            22.1G  1.18T  22.1G  -
tank/vm-116-disk-1            4.57G  1.18T  4.57G  -

es geht mir vor allem um den roten mountpoint. Dieser ist mit 81GB belegt, nutzt aber 160GB...

Code:
zfs list -t snapshot
NAME                                             USED  AVAIL  REFER  MOUNTPOINT
rpool/data/subvol-110-disk-1@V0         26.6M      -   885M  -
rpool/data/subvol-110-disk-1@V1         1.17M      -   889M  -
rpool/data/subvol-110-disk-1@V2         1.12M      -   889M  -
rpool/data/subvol-110-disk-1@V3         1.66M      -   890M  -
rpool/data/subvol-110-disk-1@V4         21.7M      -   912M  -
rpool/data/subvol-110-disk-2@V5               0      -    96K  -
rpool/data/subvol-110-disk-2@V6               0      -    96K  -
rpool/data/subvol-110-disk-2@V7               0      -    96K  -
rpool/data/subvol-111-disk-1@V8         11.2M      -  2.49G  -
tank/subvol-111-disk-1@V9                  831K      -   159G  -

wie ihr seht, taucht die CT109 nicht in den Snapshots auf.

edit: und noch eine kleine Verständnisfrage: ich habe ein ZFS-RaidZ1 aus 3*1TB. Warum habe ich nur 1.4TB verfügbar? Müssten es nicht 2TB sein?
 
Zuletzt bearbeitet:
Hi,
Auf eine meiner LXC versuchen sich immer viele Leute zugriff zu verschaffen. Wie kann ich die Quell-IPs sperren? fail2ban läuft zwar, aber ich will die IPs dauerhaft sperren. Unter "Firewall" in der LXC habe ich die Quell-IP eingetragen, dann "drop". Ein Interface kann ich aber nicht angeben, da es angeblich nicht dem net/d+ oder so standard entspricht. Unter dem Proxmox-Host selber kann ich was angeben, aber welches Interface nehme ich da? eth1 oder vmbr0?

Auch würde ich gerne, dass 2-3 LXC/VMs mit einem zweiten Server über 10Gbe kommunizieren sollen. Wo trage ich das in die hosts datei ein? Unterm Host oder bei jedem Gast oder überall?
 
Snapshots: Ja, aber nicht von der betreffenden CT.
...

es geht mir vor allem um den roten mountpoint. Dieser ist mit 81GB belegt, nutzt aber 160GB...

Code:
zfs list -t snapshot
NAME                                             USED  AVAIL  REFER  MOUNTPOINT
rpool/data/subvol-110-disk-1@V0         26.6M      -   885M  -
rpool/data/subvol-110-disk-1@V1         1.17M      -   889M  -
rpool/data/subvol-110-disk-1@V2         1.12M      -   889M  -
rpool/data/subvol-110-disk-1@V3         1.66M      -   890M  -
rpool/data/subvol-110-disk-1@V4         21.7M      -   912M  -
rpool/data/subvol-110-disk-2@V5               0      -    96K  -
rpool/data/subvol-110-disk-2@V6               0      -    96K  -
rpool/data/subvol-110-disk-2@V7               0      -    96K  -
rpool/data/subvol-111-disk-1@V8         11.2M      -  2.49G  -
tank/subvol-111-disk-1@V9                  831K      -   159G  -

wie ihr seht, taucht die CT109 nicht in den Snapshots auf.

...

Da taucht sehr wohl ein Snapshot für das rot markierte ZVOL auf, und zwar in der letzten Zeile (tank/subvol-111-disk-1@V9).

Gib' mal die Ausgabe von "zfs list -t all -o space -r tank" an. Da lässt sich besser ablesen, wieviel Daten von den Datasets und Snapshots belegt werden.
 
Zuletzt bearbeitet:
Nachdem einige Lab Server schon lange die Beta fahren (unter anderem bessers PCI Passthrough der Tesla für Tensorflow) hab ich heute mal den ersten Produktiv Server (ohne Cluster) in-place aktualisiert. Alles ohne Probleme! Nächste Woche ist das erste Cluster dran.
 
So, gerade eben den Produktiv Cluster hochgezogen....problemlos!

By the way, für schnelle reboots hab ich da endlich mal kexec zum laufen bekommen, damit booten unsere Server in knapp 20 Sekunden den neuen Kernel !!!11111einseinself!!!
 
Ich überlege aktuell in meinen Proxmox das ZFS-Raid1 aus zwei 850 Evo SSDs aufzulösen und beide SSDs als Einzellaufwerke einzubinden.
Grund:
- ZFS unterstützt kein TRIM
- Der Ausfall einer SSD ist ja unwahrscheinlicher als der einer HDD - und wenn, dann sind ja auch Backups da.

Fragen:
- Wie sollen die SSDs formatiert werden? ext4? LVM? oder wie?
- Ich habe noch einen ZFS-RaidZ1 aus 3 HDDs. Ist das ausreichend schnell um hier LXC-Container drauf laufen zu lassen? Primär geht es mir um eine Nextcloud-Instanz. Wie sieht es mit KVM aus? Hier speziell Windows. Würde ich hier einen nennenswerten Unterschied merken? Nagut, das könnte ich ja recht einfach testen indem ich den Container verschiebe.
- oder soll ich doch bei ZFS bleiben?
 
ZFS kann schon Trim Features - OpenZFS

Unter PVE krieg ich das momentan aber nur mit KVMs und SCSI Adapter hin. Für die LXCs hab ich noch nix. Merke aber auch auf meinem Produktiv Cluster auf Arbeit keine Einbußen.
 
Unter Solaris und BSD geht bei ZFS auch Trim.

Man sollte nicht immer alles verallgemeinern . 5sek Google :)

Gesendet von meinem PLK-L01 mit Tapatalk
 
Da es sich hier aber um den PROXMOX-Thread handelt, was bekanntlich unter LINUX und NICHT unter BSD/Solaris läuft und unter Linux von ZFS KEIN Trim unterstützt wird, ist meine Aussage richtig. Das weiß ich auch ohne Google :bigok:
Oder habt ihr das BSD/Solaris ZFS statt dem ZFS On Linux auf eurem Proxmox-Server ans laufen gebracht? :hmm::rofl:
 
Zuletzt bearbeitet:
Die Encryption ist noch nicht im Proxmox Installer integriert, oder? Also müsste man zuvor ein Debian mit LUKS aufsetzen und anschliessend Proxmox aus dem jeweiligen Repository manuell nachinstallieren?
 
Jups. Bzw. nutze ich einfach die LUKS Sachen nur für extra Datastores....ob das PVE rootfs verschlüsselt ist, ist mir wumpe ;)
 
Dann sollte es heißen ZoL kann kein Trim :)
 
Ok jetzt habe ich verallgemeinert.
:)

Gesendet von meinem PLK-L01 mit Tapatalk
 
Ich hatte diese kognitive Grundleistung vorausgesetzt, dass man versteht, dass es sich um die LINUX-Variante von ZFS in einem Thread über ein LINUX-Betriebssystem geht. Scheinbar habe ich da die kognitive Grundleistung bei manchen überschätzt :fresse:
 
Hat jemand Erfahrungen mit der Migration einer Windows-Maschine (hier: Windows Server 2008 Standard x64) nach Proxmox?
Ich habe einen solche physische Maschine, die bereits einige Jahre läuft und würde gerne ohne Neuinstallation nach Proxmox 4.4 umziehen.

Meine größte Sorge ist, dass ich den HW-Support für den Raid-Controller nicht in der VM abgebildet bekomme.
Der Rechner ist ein Fujitsu-Siemens Primergy TX150 S6 und der hat einen LSI onboard Raid-Controller über den 4 SAS-Platten angeschlossen sind.

Welche Vorgehensweise ist hier die Beste?
Vielen Dank!
 
Zieh einfach ein aktuelles Backup und mach den Restore dann in der neuen VM. Du kannst auch disk2vhd hernehmen und die vhd mit qemu-img konvertieren sofern deine Applikationen nicht laufen oder mitspielen (vss).

Im Proxmox Wiki gibt es dazu auch diverse Erklärungen/Varianten.
 
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