[Sammelthread] Proxmox Stammtisch

Warum nutzt du nicht nextcloud?

NextCloud ist eines von den Überteilen, mit denen man sich ansatzweise sowas wie eine Google Gsuite basteln kann. Es ist aber das absolute "Softwaremonster"und kombiniert alles was regelmäßig als Sicherheitsproblem gilt (Webserver, PHP, SQL, SSL + die tausend Add-Ons). Die Probleme die es regelmäßig auch mit dem ansich kleineren Packet Typo3 gibt sollten da eine Warnung sein. NextCloud ist daher eine sicherheitstechnisch sehr aufwändig zu wartende Sache. Durch die vielen Abhängigkeiten ist zudem Virtualisierung ein Muss um das Basissystem stabil zu halten.

Meistens nutzt man aber eh nur den Sync and Share Teil. Also einen Cloudspeicher zum Syncronisieren des Laptop/Desktops per Webbrowser oder Sync Tool und eventuell zum anonymen Sharen eines Dokuments per Weblink.

Ich nutze dafür nur noch Amazon Simple Storage S3 mit dem OpenSource Programm minIO. Im Gegensatz zu Nextcloud ist das nur eine einzige zu startende Datei unter Linux/Unix. Das muss man nicht virtualisieren, hat keinerlei Abhängigkeiten und ist zudem von der Performance unerreicht schnell.

Ich hab für Unix/OmniOS ein paar Infos zusammengefasst wie ich das unter ZFS als zusätzliche Sharing Option/ZFS Eigenschaft neben NFS und SMB nutze. Das meiste ist aber Linux/Unix unabhängig, https://forums.servethehome.com/index.php?threads/amazon-s3-compatible-zfs-cloud-with-minio.27524/
 
Zuletzt bearbeitet:
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Der Knackpunkt ist aber: bei Nextcloud sind meine Daten bei mir. Bei Amazon nicht.

Ich habe hier sensible Forschungsdaten und die würde ich niemals aus der Hand geben.
 
ZFS ist Basis für einen Fileserver im LAN auf dem man direkt mit Protokollen wie FC/iSCSI, NFS oder SMB arbeiten kann. Es hat Redundanz, Versionierung, Datensicherheit und Verschlüssellung. Einen Clusterbetrieb unterstützt ZFS nicht direkt, man kann einzelne ZFS Filer aber als Cluster Nodes nutzen. Im Internet sollte man die üblichen Fileserver Protokolle wie NFS oder SMB auf gar keinen Fall nutzen. Internet ist ja für direktes Arbeiten auf dem Server wie über SMB eh viel zu langsam (daher Cloud=sync and share).

Amazon S3 kann man zunächst als Sharing Protokoll wie ftps oder https sehen, nur halt ausgelegt auf Internet Objectstorage und Cloud sync and share. Mit minIO kann man damit S3 Cloud Sharing/ Veeam/ Cloud Backup für einen ZFS Filer nachrüsten.

Mit S3 und minIO kann man nicht nur ein ZFS Dateisystem im Internet freigeben sondern auch Cluster aus vielen Servern aufbauen um Redundanz, Performance und ultrahohe Kapazität zu erreichen. Amazon selber arbeitet mit seiner S3 Infrastruktur so aber für sehr viele Anforderungen (außer 99,99999% uptime und Exa/Zettabyte Storage) ist S3 auf einem ZFS single Server perfekt, eventuell ergänzt um ein Dualhead HA Cluster. Zusätzlich kann man so S3 inhouse anbieten und muss nicht eigene Daten auf Amazon Servern irgendwo in der Welt speichern.

Ceph ist ein Cluster Dateisystem das in seinen Features noch über S3 hinausgeht, aber dafür deutlich komplexer und auch langsamer ist als S3 das "nur" die Funktion Cloud/Objekt Storage abdeckt.

S3 mit single node auf ZFS ist dagen das was man als idiotensicher/ dau kompatibel bezeichnen kann wenn man nichts anderes will als einen lokalen Filer auch zusätzlich als sicheren Cloudstorage im Internet zu nutzen.
 
Zuletzt bearbeitet:
Hat hier jemand zufällig erfolgreich eine AMD GPU and eine Linux VM durchgereicht? Ich möchte eine Sapphire RX580 Nitro+ an eine LinuxVM durchreichen (habe Arch Linux und Ubuntu versucht), erhalte aber weder ein Bild direkt von der Grafikkarte, noch kann ich mich mit den auf der VM automatisch startenden TeamViewer verbinden. DIe proxmox interne noVNC Konsole zeigt bloss Guest has not initialized the display (yet).

Host ist der folgende:
  • CPU: AMD Ryzen 3950X
  • Mainboard: Gigabyte Aorus Ultra, Virtualisierungs-Sachen (virtualisation, IOMMU, ARI, ACS) sind alle eingeschaltet
  • GPU: Sapphire RX580 Nitro+ 4G
proxmox ist up-to-date mit Kernel 5.4.
Code:
proxmox-ve: 6.1-2 (running kernel: 5.4.27-1-pve)
pve-manager: 6.1-8 (running version: 6.1-8/806edfe1)
pve-kernel-5.4: 6.1-8
pve-kernel-helper: 6.1-8
pve-kernel-5.3: 6.1-6
pve-kernel-5.4.27-1-pve: 5.4.27-1
pve-kernel-5.3.18-3-pve: 5.3.18-3
pve-kernel-5.3.18-2-pve: 5.3.18-2
ceph-fuse: 12.2.11+dfsg1-2.1+b1
corosync: 3.0.3-pve1
criu: 3.11-3
glusterfs-client: 5.5-3
ifupdown: 0.8.35+pve1
ksm-control-daemon: 1.3-1
libjs-extjs: 6.0.1-10
libknet1: 1.15-pve1
libpve-access-control: 6.0-6
libpve-apiclient-perl: 3.0-3
libpve-common-perl: 6.0-17
libpve-guest-common-perl: 3.0-5
libpve-http-server-perl: 3.0-5
libpve-storage-perl: 6.1-5
libqb0: 1.0.5-1
libspice-server1: 0.14.2-4~pve6+1
lvm2: 2.03.02-pve4
lxc-pve: 3.2.1-1
lxcfs: 4.0.1-pve1
novnc-pve: 1.1.0-1
proxmox-mini-journalreader: 1.1-1
proxmox-widget-toolkit: 2.1-3
pve-cluster: 6.1-4
pve-container: 3.0-23
pve-docs: 6.1-6
pve-edk2-firmware: 2.20200229-1
pve-firewall: 4.0-10
pve-firmware: 3.0-7
pve-ha-manager: 3.0-9
pve-i18n: 2.0-4
pve-qemu-kvm: 4.1.1-4
pve-xtermjs: 4.3.0-1
qemu-server: 6.1-7
smartmontools: 7.1-pve2
spiceterm: 3.1-1
vncterm: 1.6-1
zfsutils-linux: 0.8.3-pve1

In GRUB habe ich: GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0 quiet amd_iommu=on iommu=pt video=efifb:off"

amdgpu und radeon Treiber sind blacklistet und werden auch nicht geladen. Die GPU wird glaube ich auch nicht vom host übernommen, da die Lüfter auf 100% weiterdrehen, was sonst (auch unter proxmox) nicht der Fall ist.

Die VM ist wie folgt eingerichtet:
Code:
agent: 1
balloon: 8192
bios: ovmf
bootdisk: scsi0
cores: 12
cpu: host
efidisk0: VMstorage:vm-102-disk-1,size=1M
hostpci0: 0a:00,pcie=1,romfile=sapphire.rom
ide2: local:iso/ubuntu-20.04-desktop-amd64.iso,media=cdrom
machine: q35
memory: 60000
name: Ubuntu
net0: virtio=B2:5E:C6:CA:A0:A5,bridge=vmbr0,firewall=1
numa: 1
ostype: l26
scsi0: VMstorage:vm-102-disk-0,cache=writeback,discard=on,size=32G,ssd=1
scsihw: virtio-scsi-pci
shares: 5000
smbios1: uuid=bd85f4fe-370e-4299-9ce2-a39f2f997fe9
sockets: 1
vmgenid: fdfa3441-a8f0-48f5-8063-2d633183ffa4

Syslog beim Start der VM mit GPU:
Code:
Apr 24 16:18:00 pvehost systemd[1]: Starting Proxmox VE replication runner...
Apr 24 16:18:00 pvehost systemd[1]: pvesr.service: Succeeded.
Apr 24 16:18:00 pvehost systemd[1]: Started Proxmox VE replication runner.
Apr 24 16:18:27 pvehost pvedaemon[5286]: start VM 102: UPID:pvehost:000014A6:00012328:5EA2F533:qmstart:102:root@pam:
Apr 24 16:18:27 pvehost pvedaemon[1520]: <root@pam> starting task UPID:pvehost:000014A6:00012328:5EA2F533:qmstart:102:root@pam:
Apr 24 16:18:27 pvehost kernel: pcieport 0000:00:03.1: AER: Uncorrected (Non-Fatal) error received: 0000:00:03.1
Apr 24 16:18:27 pvehost kernel: pcieport 0000:00:03.1: AER: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
Apr 24 16:18:27 pvehost kernel: pcieport 0000:00:03.1: AER:   device [1022:1483] error status/mask=00100000/04400000
Apr 24 16:18:27 pvehost kernel: pcieport 0000:00:03.1: AER:    [20] UnsupReq               (First)
Apr 24 16:18:27 pvehost kernel: pcieport 0000:00:03.1: AER:   TLP Header: 34000000 0a000010 00000000 80008000
Apr 24 16:18:27 pvehost kernel: pcieport 0000:00:03.1: AER: Device recovery successful
Apr 24 16:18:27 pvehost systemd[1]: Started 102.scope.
Apr 24 16:18:27 pvehost systemd-udevd[5290]: Using default interface naming scheme 'v240'.
Apr 24 16:18:27 pvehost systemd-udevd[5290]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr 24 16:18:27 pvehost systemd-udevd[5290]: Could not generate persistent MAC address for tap102i0: No such file or directory
Apr 24 16:18:27 pvehost kernel: device tap102i0 entered promiscuous mode
Apr 24 16:18:27 pvehost systemd-udevd[5290]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr 24 16:18:27 pvehost systemd-udevd[5290]: Could not generate persistent MAC address for fwbr102i0: No such file or directory
Apr 24 16:18:27 pvehost systemd-udevd[5289]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr 24 16:18:27 pvehost systemd-udevd[5296]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
Apr 24 16:18:27 pvehost systemd-udevd[5289]: Using default interface naming scheme 'v240'.
Apr 24 16:18:27 pvehost systemd-udevd[5296]: Using default interface naming scheme 'v240'.
Apr 24 16:18:27 pvehost systemd-udevd[5296]: Could not generate persistent MAC address for fwln102i0: No such file or directory
Apr 24 16:18:27 pvehost systemd-udevd[5289]: Could not generate persistent MAC address for fwpr102p0: No such file or directory
Apr 24 16:18:27 pvehost kernel: fwbr102i0: port 1(fwln102i0) entered blocking state
Apr 24 16:18:27 pvehost kernel: fwbr102i0: port 1(fwln102i0) entered disabled state
Apr 24 16:18:27 pvehost kernel: device fwln102i0 entered promiscuous mode
Apr 24 16:18:27 pvehost kernel: fwbr102i0: port 1(fwln102i0) entered blocking state
Apr 24 16:18:27 pvehost kernel: fwbr102i0: port 1(fwln102i0) entered forwarding state
Apr 24 16:18:27 pvehost kernel: vmbr0: port 2(fwpr102p0) entered blocking state
Apr 24 16:18:27 pvehost kernel: vmbr0: port 2(fwpr102p0) entered disabled state
Apr 24 16:18:27 pvehost kernel: device fwpr102p0 entered promiscuous mode
Apr 24 16:18:27 pvehost kernel: vmbr0: port 2(fwpr102p0) entered blocking state
Apr 24 16:18:27 pvehost kernel: vmbr0: port 2(fwpr102p0) entered forwarding state
Apr 24 16:18:27 pvehost kernel: fwbr102i0: port 2(tap102i0) entered blocking state
Apr 24 16:18:27 pvehost kernel: fwbr102i0: port 2(tap102i0) entered disabled state
Apr 24 16:18:27 pvehost kernel: fwbr102i0: port 2(tap102i0) entered blocking state
Apr 24 16:18:27 pvehost kernel: fwbr102i0: port 2(tap102i0) entered forwarding state
Apr 24 16:18:33 pvehost kernel: vfio-pci 0000:0a:00.0: vfio_ecap_init: hiding ecap 0x19@0x270
Apr 24 16:18:33 pvehost kernel: vfio-pci 0000:0a:00.0: vfio_ecap_init: hiding ecap 0x1b@0x2d0
Apr 24 16:18:33 pvehost kernel: vfio-pci 0000:0a:00.0: vfio_ecap_init: hiding ecap 0x1e@0x370
Apr 24 16:18:34 pvehost kernel: pcieport 0000:00:03.1: AER: Uncorrected (Non-Fatal) error received: 0000:00:03.1
Apr 24 16:18:34 pvehost kernel: pcieport 0000:00:03.1: AER: PCIe Bus Error: severity=Uncorrected (Non-Fatal), type=Transaction Layer, (Requester ID)
Apr 24 16:18:34 pvehost kernel: pcieport 0000:00:03.1: AER:   device [1022:1483] error status/mask=00100000/04400000
Apr 24 16:18:34 pvehost kernel: pcieport 0000:00:03.1: AER:    [20] UnsupReq               (First)
Apr 24 16:18:34 pvehost kernel: pcieport 0000:00:03.1: AER:   TLP Header: 34000000 0a000010 00000000 80008000
Apr 24 16:18:34 pvehost kernel: pcieport 0000:00:03.1: AER: Device recovery successful
Apr 24 16:18:34 pvehost pvedaemon[1520]: <root@pam> end task UPID:pvehost:000014A6:00012328:5EA2F533:qmstart:102:root@pam: OK
Apr 24 16:19:00 pvehost systemd[1]: Starting Proxmox VE replication runner...
Apr 24 16:19:00 pvehost systemd[1]: pvesr.service: Succeeded.
Apr 24 16:19:00 pvehost systemd[1]: Started Proxmox VE replication runner.
Apr 24 16:20:00 pvehost systemd[1]: Starting Proxmox VE replication runner...
Apr 24 16:20:00 pvehost systemd[1]: pvesr.service: Succeeded.
Apr 24 16:20:00 pvehost systemd[1]: Started Proxmox VE replication runner.
Apr 24 16:21:00 pvehost systemd[1]: Starting Proxmox VE replication runner...
Apr 24 16:21:00 pvehost systemd[1]: pvesr.service: Succeeded.
Apr 24 16:21:00 pvehost systemd[1]: Started Proxmox VE replication runner.
Apr 24 16:21:05 pvehost systemd[1]: Starting Cleanup of Temporary Directories...
Apr 24 16:21:05 pvehost systemd[1]: systemd-tmpfiles-clean.service: Succeeded.
Apr 24 16:21:05 pvehost systemd[1]: Started Cleanup of Temporary Directories.
Apr 24 16:21:37 pvehost pvedaemon[1520]: <root@pam> successful auth for user 'root@pam'
Apr 24 16:22:00 pvehost systemd[1]: Starting Proxmox VE replication runner...
Apr 24 16:22:00 pvehost systemd[1]: pvesr.service: Succeeded.
Apr 24 16:22:00 pvehost systemd[1]: Started Proxmox VE replication runner.
Apr 24 16:23:00 pvehost systemd[1]: Starting Proxmox VE replication runner...
Apr 24 16:23:00 pvehost systemd[1]: pvesr.service: Succeeded.
Apr 24 16:23:00 pvehost systemd[1]: Started Proxmox VE replication runner.
Apr 24 16:23:02 pvehost pvedaemon[6094]: starting vnc proxy UPID:pvehost:000017CE:00018E7A:5EA2F646:vncproxy:102:root@pam:
Apr 24 16:23:02 pvehost pvedaemon[1520]: <root@pam> starting task UPID:pvehost:000017CE:00018E7A:5EA2F646:vncproxy:102:root@pam:
Apr 24 16:23:05 pvehost pvedaemon[1520]: <root@pam> end task UPID:pvehost:000017CE:00018E7A:5EA2F646:vncproxy:102:root@pam: OK
Server View

Ich weiss langsam nicht, was ich sonst noch ausprobieren könnte. :/ Testweise habe ich eine Netzwerkkarte durchgereicht, dass hat zumindest geklappt. Aber die GPU will einfach nicht. :/
 
Habe die ROM testweise geladen, da es manchmal helfen soll. Aber mit oder ohne ROM, auch mit machine: pc-q35-3.1 erhalte ich nur Status: internal error und kann nicht auf die VM zugreifen (TeamViewer oder noVNC).
 
Nachdem ich im BIOS (host) ARI, ACS und AER ausgeschaltet habe, klappt der passthrough. :) Dafür kann ich mich jetzt bei meiner Ubuntu VM nicht einloggen. Sobald ich das Passwort eingebe und enter drücke, wird der Bildschirm schwarz und ich bin wieder beim Login-Bildschirm. :/

Edit: ich musste "Ubuntu on Wayland" auswählen, damit ich mich einloggen konnte.
Beitrag automatisch zusammengeführt:

Nun habe ich aber das Problem, dass ich die VM nicht neu starten kann, ohne den Host selbst auch neu zu starten...
 
Zuletzt bearbeitet:
So, machine wieder auf q35 zurückstellen und ein qm set ID -args '-machine type=q35,kernel_irqchip=on' scheint geholfen zu haben. Nun klappt auch ein Reboot aus der VM selbst heraus (manchmal). Reboot über proxmox klappt jedoch nicht.
 
Zuletzt bearbeitet:
So, ich habe nun ein Setting gefunden, mit welchem GPU passthrough, mit relativ wenigen Einschränkungen funktioniert. Shutdown der VM (aus der VM raus) und späterer Neustart (vom Host aus) funktioniert nicht. Reboot von der VM aus funktioniert jedoch.

Grundsätzlich habe ich mich an folgenden Guides orientiert: [1], [2], [3], [4]
Nebst den dort aufgeführten Massnahmen musste ich noch folgendes machen:
  • ARI, AER, ACS im BIOS deaktivieren
  • qm set ID -args '-machine type=q35,kernel_irqchip=on' [5]
  • GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0 biosdevname=0 quiet amd_iommu=on iommu=pt video=efifb:off"
    • video=efifb:off ist nicht nötig, läuft bei mir auch ohne dieses Argument!
  • statt radeon muss amdgpu auf die Treiber-blacklist
Meine Konfig ist:

Code:
agent: 1
args: -machine type=q35
audio0: device=ich9-intel-hda,driver=spice
balloon: 8192
bios: ovmf
bootdisk: scsi0
cores: 12
cpu: host
efidisk0: VMstorage:vm-102-disk-1,size=1M
hostpci0: 0a:00,pcie=1
machine: q35
memory: 60000
name: Ubuntu
net0: virtio=B2:5E:C6:CA:A0:A5,bridge=vmbr0,firewall=1
numa: 1
ostype: l26
scsi0: VMstorage:vm-102-disk-0,cache=writeback,discard=on,size=32G,ssd=1
scsihw: virtio-scsi-pci
shares: 5000
smbios1: uuid=bd85f4fe-370e-4299-9ce2-a39f2f997fe9
sockets: 1
usb0: host=046d:c52b,usb3=1
usb1: host=1af3:0001,usb3=1
usb2: host=04d9:0169,usb3=1
usb3: host=046d:0819,usb3=1
usb4: host=048d:8297,usb3=1
vga: none
vmgenid: fdfa3441-a8f0-48f5-8063-2d633183ffa4

Vielleicht dient dies ja sonst jemandem mit einem ähnlichen Problem...

Edit: Konnte die Einschränkungen noch etwas reduzieren (durchgestrichene Sachen waren doch nicht nötig).
 
Zuletzt bearbeitet:
Ich habe da eine Konfigurationsfrage zu Clustern.
Ich habe ein 2-Node-Cluster, wobei Node 2 nur bei Bedarf läuft. Wenn der RAM auf Node 1 voll wird, möchte ich gerne Node 2 per WOL starten (das funktioniert) und möchte gerne die Live-Migration nutzen, um die LXCs auf den zweiten Node zu migrieren. Auf Node 1 läuft ZFS und ich möchte natürlich weiterhin Snaphots nutzen können. Aber für die Live-Migration muss es ja auf einem Shared-Storage liegen, und ZFS kann man ja scheinbar nicht für eine zweite Node freigeben. Und mit NFS funktioniert natürlich kein Snapshot mehr.
Habt ihr da eine Lösung?
 
Es gibt zwei Lösungswege mit ZFS

1. NFS auf einem ZFS Dateisystem. Da werden Snaps gemacht und das NFS Share wird entweder aif Node 1 oder Node 2 gemounted. Man muss Vorkehrungen treffen damit das Share nicht gleichzeitig genutzt wird.

2. Ein ZFS Pool mit Multipath z.B. SAS Platten. Je einen SAS Anschluß einer Platte geht zu Node 1, der andere zu Node 2. Damit sehen beide Nodes die Platten. Man muss Vorkehrungen treffen damit die Platten nicht gleichzeitig genutzt werden. Diese Lösung nutze ich unter ZFS als Cluster in a Box unter Solarish, prinzipiell ließe sich das auch unter Linux realisieren, http://www.napp-it.org/doc/downloads/z-raid.pdf

Lösung 2 ist viel schneller da kein Netzwerk benutzt wird sondern direkter Plattenzugriff.
 
Leg am zweiten Server ebenfalls einen zfs Pool an. Dann kannst du die Replikation/Live Migration nutzen, ein Shared Storage ist dafür nicht notwendig.
 
Aktuell ist kein zfs am zweiten node möglich.
Ich habe einen NFS Share erstellt, da funktioniert aber snapshots nicht.
edit: der Grund, warum Snapshots unter NFS nicht funktioniert: Das Volume wird in ein RAW umformatiert und nutzt keine ZFS "Partition" (komme gerade nicht auf den korrekten Namen).
 
Zuletzt bearbeitet:
Ich bin nicht sicher, ob das so klappt,vaber Du könntest auf Host A ein zfs-over-isci storage erstellen und dann wechselweise mounten.
 
Das ist ja auch total umständlich.

der Grund, warum Snapshots unter NFS nicht funktioniert: Das Volume des LXC wird in ein RAW umformatiert und nutzt keine ZFS "Partition" (komme gerade nicht auf den korrekten Namen).

edit: wie sieht es mit "zfs set sharenfs=on /tank/nfs" aus? Wie mountet man das in Proxmox?
 
Zuletzt bearbeitet:
Dataset/Filesystem.

Du willst halt auch etwas für Deinen ganz speziellen Fall, der gänzlich an jeder üblichen Praxis vorbeigeht.
Was ist der Grund, dass Du Node B nicht auf zfs umstellen kannst? Zumal er doch eh die meiste Zeit schläft?
CephFS kannst Du Dir auch noch ansehen, wobei dafür üblicherweise 3 Nodes benötigt werden und Du das Quorum auf dem Primärnode erhöhen müsstest.

Eine Zweizeiler Lösung im Sinne von "mach da den Haken rein und wähl dort dies aus" wirst Du nicht finden.
 
Der Grund ist, dass ich keine Festplatten vorrätig habe und ich auch nicht vor Ort bin, sondern alles Remote mache. Aber wenn ich da mal ZFS einrichte, muss dann der Poolname identisch sein?

Weiteres Problem:
Wenn Node 2 offline geht, geht die Load von Node 1 hoch, da der natürlich versucht auf shares auf node 2 zuzugreifen. Gibt es da einen Workaround?
 
Da es um LXC geht und nicht um VMs geht zfs over iscsi (leider) nicht.
Klassisches iSCSI und darauf dann zfs sollte aber gehen oder du könntest eine Art pseude zfs auf node2 machen:
Also eine zfs.img erstellen und das dann als zfs formatieren und mounten. Ka wie das mit Leistung ist, aber könnte klappen und dann wenn wieder vor Ort auf eine HDD/SSD umziehen.
Sonst wäre Ceph oder vll gluster eine Idee, aber ka ob da snapshots gehen.
 
Hi,
ich habe jetzt ZFS über ISCSI in Proxmox eingebunden, jedoch kann ich keine LXCs dort drauf speichern. Wie kann man das machen? So wie ich das sehe, kann man nur VMs darauf installieren, da ich aber keine VMs nutze, ist das absolut sinnfrei.

Was ist denn der Grund, warum man überhaupt in Proxmox Clustern kann, wenn man noch nichtmal ein verteiltes Dateisystem mit Snapshots für LXC nutzen kann??

was auch komisch ist: seit gestern steigt die Load-Average auf Node 1 auf 500 % an, wenn Node 2 offline ist. Es existiert kein Shared storage auf Node 2 (allesamt deaktiviert), dennoch steigt es wieder an. Ich glaube, es liegt daran: "
Apr 28 11:48:04 pve kernel: nfs: server 192.168.20.10 not responding, timed out
Apr 28 11:48:06 pve kernel: nfs: server 192.168.20.10 not responding, still trying

Das ist auf Node 2. Aber Node 2 hat keinen NFS share?
 

Anhänge

  • Load.PNG
    Load.PNG
    4,9 KB · Aufrufe: 239
Zuletzt bearbeitet:
LXC bringt entsprechenden Snapshot Support mit, dazu muss aber auch dein Storage mitspielen. NFS/CIFS oder Block-Lösungen wie iSCSI/Gluster, bringen eben NICHT den notwendigen Support mit. Hier musst du die Backups darunterliegend erledigen (z.B. LVM oder ZFS Snapshots). Auch Ceph ist für dich keine Option, du hast keinen aktiven Cluster der dauerhaft den Sync ermöglicht.

Wenn ZFS vorerst keine Option ist, würde ich am Host1 eine NFS Freigabe per ZFS erstellen. DIe Container kannst du dann wie gewünscht zwischen den Hosts hin und herschieben. Für Backups musst du dann mit ZFS Snaphots am Host1 vorlieb nehmen müssen. In 8-10 Monaten wirst du mit "Proxmox Backup" womöglich eine Lösung bekommen die auch deine Anforderung besser abdeckt.
 
ZFS over iSCSI kann Snapshots, du kannst darüber aber auch andere Filesysteme nutzen. Der Snapshotsupport kommt durch ZFS und nicht iSCSI.

Ich hätte NFS verwendet da es in deiner recht "speziellen" Umgebung weniger Probleme machen sollte. Die Snapshots/Backups müsstest du dann aber wie gesagt über ZFS auf Filesystemebene lösen. Dazu findest du auch diverse Tools die es einfacher machen, z.B. zfssnap, znapzend,...
 
Ich habe nun auf dem zweiten Node zwei ZFS aus einzel-Disks erstellt.
Wie kann ich das nun machen?
 
Was machen? Snapshots gehen dann ootb. Die MIgration erfordert im Grunde nur das deine Pools auf beiden Clusterknoten mit dem selben Namen definiert sind.
 
Muss da nicht der "Storage" den selben Namen haben? Denn der meldet immer "ZFSTank (Name des Storage) nicht auf Node 2 vorhanden". Wenn ich aber ein zweites Storage mit "ZFSTank" anlegen will, meldet der immer "bereits vorhanden".
 
Hallo zusammen,

da mir das letzte mal so gut geholfen wurde (danke dafür), kommt gleich noch zwei Fragen ;)
-ich habe Proxmox bei mir auf einer alten Hardware installiert. War eigentlich nur zum Test gedacht, ist aber für eine ganze Zeit ein produktives System gewesen. Jetzt will ich aber den kompletten Server auf eine potente HW umziehen. Wie stelle ich das am besten an?
-aktuell lasse ich regelmäßig automatisch ein Backup auf ein NFS-Laufwerk machen. Leider kann dieser nur immer ein einziges Backup machen und löscht die alten. Woran liegt das? Die Einstelleungen, welche ich gegooglet habe, kann ich leider nicht finden.

Danke und Grüße :)
 
1. zu präferieren seitens Proxmox ist immer Shutdown der Maschine, Backup, Transfer des Backups per scp o.ä., restoren auf dem neuen Node. Wenn die Versionen ähnlich sind, könntest Du noch einen Cluster bilden, dabei müsste der alte der Master sein (da auf den Slaves keine Maschinen liegen dürfen). Dort dann Live Migration. Vorteil: kürzere Downtime, höheres Risiko mit wenig Nutzen, wenn der Cluster nicht dauerhaft bestehen soll. Ich würde Backup/Restore empfehlen.
2. Ein aktuelles Proxmox vorausgesetzt (ich habe 6.1), WebGUI: Datacenter > Storage > local (NICHT: local-zfs) > Max Backups: 1 -> x > ändern, speichern etc.
 
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