Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
Ohne zu lesen würde ich jetzt mal sagen, dass mal einen Pool nicht nachträglich verschlüsseln kann, da müsste man sicher einen neuen auf anderen Platten erstellen und die Daten dann via zfs senden.
Native ZFS encryption ist keine Pool Eigenschaft sondern Eigenschaft eines einzelnen ZFS Dateisystems. Dadurch kann man je Dateisystem entscheiden ob man das verschlüsseln möchte und man kann auch je Dateisystem einen anderen Schlüssel verwenden.
Also einfach ein verschlüsseltes Dateisystem anlegen und da die Daten reinkopieren, per zfs send oder cp/rsync
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Was gea schrieb, wollte ich ähnlich auch vor einigen Stunden schreiben, aber dann kam eine Geburtstagsfeier dazwischen.
Meine Ergänzung hierzu: wenn man zfs Datasets auf einem normalen zfs Pool angelegt hat, dann geht das ohne weiteres über zfs send oder rysnc o.ä.
Wenn man jedoch auch vorher schon per luks verschlüsselte Platten hatte (wie ich), dann wird das etwas schwieriger. Zfs Datasets können von der Größe zwar beliebig skalieren, aber die luks sind Partitionen mit festen Sektorgrenzen. Da wäre es das einfachste und sicherste, ein bis zwei weitere Platten zu nehmen, dorthin zu schicken, danach Pool neu erstellen und dort dann die Datasets verschlüsselt anzulegen und zurück zu schicken.
Mit der encryption werde ich mal noch Performance testen. Habe ja auch aktuell LUKS drunter, das ist alles schon hardwarebeschleunigt. Bei ZFS ist da ja noch was unklar seit den letzten Kernelsymboländerungen: no SIMD acceleration · Issue #8793 · zfsonlinux/zfs · GitHub
Wäre toll, wenn du dann die Resultate hier nochmal posten könntest dazu Habe ich das richtig verstanden, dass die Verschlüsselung dann nicht den gesamten Pool, sondern z.B. jeweils nur das Dataset betrifft? Ist das ganze überhaupt schon irgendwie in die Proxmox GUI eingearbeitet worden, oder muss man derzeit noch alles direkt über die Kommandozeile managen? Wie läuft das beim Systemstart ab - ich vermute, man bindet die verschlüsselten Datasets dann manuell ein, bevor man die VMs anschließend startet?
Gibt es irgendwo eine Info bzgl. ZFS-Verschlüsselung auf dem Root-Filesystem? Die bequemste Variante wäre sicher, wenn der Key bereits beim Systemstart abgefragt wird und daraufhin das Hostsystem selbst als auch die verschlüsselten VMs hochgefahren werden (ähnlich wie bei LUKS).
Liest sich sehr interessant vom Ansatz her, das werde ich dann auch mal prüfen. Ich hatte übrigens heute mal die Gelegenheit, die Proxmox 6 Beta auf einem "EX42-NVME" Rootserver von Hetzner zu testen. Die setzen dort folgende Hardware ein:
Code:
Model Number: SAMSUNG MZVLB512HAJQ-00000
Firmware Version: EXA7301Q
Dazu eine Intel Core i7 Quad-Core CPU und 64 GB DDR4 RAM. Die Installation wurde per Remote-KVM ausgeführt, der Installer erkannte die NVMe-Drives problemlos, diese habe ich dann als Mirror (RAID1) konfiguriert. Im Gegensatz zu Proxmox 5 funktioniert nun auch das Booten von den NVMe's einwandfrei. Erster Performance-Test danach:
Code:
CPU BOGOMIPS: 57600.00
REGEX/SECOND: 4497862
HD SIZE: 460.25 GB (rpool/data)
FSYNCS/SECOND: 756.72
DNS EXT: 25.01 ms
DNS INT: 33.98 ms
Mir erscheinen die FSyncs deutlich zu niedrig, dafür das es ein System ist welches komplett über SSDs läuft. Zum Vergleich unser lokaler Test-Proxmox (5) Server, bestückt mit 2x Western Digital WD Blue im ZFS-Mirror, einer 200 GB Intel DC S3700 als ZIL und Cache, 32 GB RAM und einem Xeon E3-1225:
Code:
pveperf
CPU BOGOMIPS: 25540.84
REGEX/SECOND: 3226689
HD SIZE: 711.76 GB (rpool/ROOT/pve-1)
FSYNCS/SECOND: 10782.64
DNS EXT: 27.49 ms
DNS INT: 22.37 ms
In beiden Fällen war die Option "sync=standard" gesetzt sowie "compression=lz4". Sind die Samsung MZVLB512HAJQ weniger gut geeignet für den ZFS-Betrieb? Ich vermute, das bei den anderen Servern der EX-Linie die gleiche Hardware zum Einsatz kommt, die Resultate werden dann also ähnlich sein. Interessant wäre eventuell noch, wie gut ein EX-Server mit 2x HDDs und einer Datacenter SSD als ZIL/Cache performed und ob die Server der PX-Linie nochmals besser wären (ECC-RAM und Xeon-Prozessoren). Unter Proxmox 5 und einem Software-RAID1 (LVM) sah das ganze im übrigen noch schlechter aus:
Code:
CPU BOGOMIPS: 57600.00
REGEX/SECOND: 4059054
HD SIZE: 14.70 GB (/dev/mapper/vg0-root)
BUFFERED READS: 1961.64 MB/sec
AVERAGE SEEK TIME: 0.06 ms
FSYNCS/SECOND: 274.22
DNS EXT: 37.89 ms
Wird "sync=off" gesetzt, dann erhält man FSync-Werte von knapp 40k, aber das ist natürlich nicht mehr ratsam für den Produktivbetrieb.
Von ZFS ohne ECC RAM ist für einen Produktiveinsatz absolut abzuraten.
Der fsyncs/second Wert ist für eine PM981 normal, das ist halt ne Prosumer SSD und keine echte enterprise SSD. Zum performance testen nimm besser fio, damit erhältst du dann wenigstens Werte, die du leichter vergleichen kannst. Mit sync=off testet pveperf deinen RAM und gar nicht mehr die disks - daher absolut unaussagekräftig.
Daher hatte ich die PX-Serie erwähnt (Xeon-Prozessoren und ECC-Speicher). Das mir vorliegende EX-System wurde allerdings gekündigt, so das ich hiermit noch den Bootvorgang von NVMe mit Proxmox 6 austesten konnte (was zuvor mit Proxmox 5 in Verbindung mit Grub nicht lief, zumindest nicht mit ZFS als Root-FS). Als simples Testsystem also vollkommen ausreichend. Gibt es hier im Forum evtl. schon irgendwo eine Liste mit fio-Tests zu verschiedenen SSDs?
There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.
I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.
Dann nimm halt kein ECC und nimm die Verantwortung auf dich falls doch was passiert. Findet dein Chef bestimmt geil 200€ gespart zu haben, aber den Datengau in Kauf genommen zu haben.
Unbestritten ist, dass RAM Fehler mit einer statistischen Häufigkeit auftreten, Berechnungen oder Daten verfälschen können oder den Rechner abstürzen lassen können. Ein professioneller Server ohne ECC, zumal mit etwas mehr RAM ist grob fahrlässig.
Anders sieht es mit der Aussage aus, dass ZFS in besonderem Maße ECC verlangen würde. Das könnte man allenfalls dadurch begründen, dass ZFS Server meist viel RAM haben (mehr RAM=mehr Fehler). Die Zeit wo ein Server ohne ZFS aber nur wenige MB/GB hatte sind aber längst vorbei. Auch ein normaler Windows oder Linux Server hat viel RAM und nutzt den auch zumindest zum Cachen.
Ansonsten geht das auf die Mär aus einem bestimmten Forum zurück, dass ein Ramfehler beim Lesen zu einem ZFS Prüfsummenfehler führen würde . Dieser würde eine fehlerhafte Reparatur auslösen. Bei mehreren RAM Fehlern würde sich ZFS totreparieren.
Und genau das ist falsch. ZFS erkennt ein Problem viel früher als es ntfs oder ext4 könnte (keine Prüfsummen). Die Reaktion darauf ist aber ein Disk oder Pool offline (too many errors).
Wobei man natürlich AUCH bei ZFS einen Datenverlust ohne ECC nicht ausschließen kann. Und ein RAM Fehler ist so ziemlich der einzige Fehler den ZFS nicht abfangen kann ("neben einer Amok Hardware")
Wie hieß es doch: "I would simply say: if you love your data, use ECC RAM"
proxmox ist echt interessant.
Ich habe zwei Fragen an die Profis.
1. Wie ist die Netzwerkgeschwindigkeit bei euch über Samba in der vm Umgebung. Leidet die samba Geschwindigkeit in eine vm über proxmox und wenn ja wieviel?
2. Kann ich Xpenology über die bridge in eine vm laufen lassen, ganz egal was für eine Netzwerkkarte ich habe? Der Intel Chipsatz 219LM ist leider mit Xpenology nicht kompatibel, würde es mit Proxmox trotzdem klappen?
Wie kann man die onboard-Soundkarte an eine VM durchreichen? Ich versuche es mit dem FCH Azalia Controller. Der ist aber in der gleichen IOMMU-Gruppe wie der FCH SMBus Controller.
Auch wird der Soundchip der GPU, die ebenfalls durchgereicht ist und sonst funktioniert, nicht erkannt.
Jemand eine Idee?
Nachdem auch die Beta schon auf Debian Buster lief, reicht es, die Repository Änderung rückgängig zu machen und ganz normal apt update && apt upgrade.
Das dist-upgrade war schon von Strech auf Buster notwendig (PVE5.4 > PVE6beta).
Seit Stretch (Debian 9/PVE 5) ist nach aptitude und apt-get nun übrigens apt das empfohlene Tool für die Paketinstallation und -aktualisierung (außer in Skripten, aber davon reden wir ja gerade nicht).
so... gestern abend mein Proxmox neu aufgesetzt.. geht erstmal alles bestens.
mit der integrierten Backup-Funktion die VMs gesichert, da ich mein ZFS neu zusammenstellen wollte.. also von einem Stripe auf ein RaidZ1 mit 3 Platten. Da aber eine Platte etwas kleine ist, musste ich den Befehl in der Konsole einhämmern mit einem -f Dann ging es. Und mit PVESM konnte ich das ZFS vernünftig einbinden. Den dump-Ordner mit den Backups wieder zurückgespielt.. Funktioniert.
und dann noch ein Test mit Container auf dem ZFS... geht jetzt auch bestens.
Zuletzt noch meine SSDs als Cache mit eingebunden und nun läuft die Kiste wieder weiter.
Moin,
hat mir jemand eine Idee?
Curl will sich nicht updaten lassen. Installiert ist lt. Web UI 7.52.1-5+deb9u9, current wäre 7.64.0-4. Apt meldet "[curl] have been kept back", mit dist-upgrade oder apt-mark unhold tut sich nix.
Und jetzt wo ich es sehe:
curl ist installiert, libcurl4 nicht, denn letzteres hat keine installierte Version, sondern nur eine "new". Wenn ich aber libcurl4 installieren möchte, will er mir proxmox komplett löschen (pve-manager, qemu-server etc). Es ist wohl libcurl3 installiert, das würde nämlich u.a. mit gelöscht. Da scheint der Hund begraben zu sein.
Heißt das wiederum, ich sollte curl löschen, im Sinne von "beides oder nichts"? Ich mag solche unresolved Update-Packete nicht...
Ach, und das eigentliche Problem:
Ich kann die DVB-Karte nicht an eine VM durchreichen. Bzw. genauer: Durchreichen schon, aber der Treiber in der VM produziert einen Sack voll I2C-Fehlermeldungen (2 je Tuner) und schaltet sich dann ab. Das hatte ich noch nie. Leider habe ich das erst jetzt in Buster probiert und habe leider keinen Vergleich, ob es mit 5.4 noch funktioniert "hätte". Was ich probiert habe:
- Blacklist modprobe "ddbridge" im Host
- Im VM-Treiber MSI für die Karte abgestellt
In der PT-Funktion des Proxmox:
- PT mit PCIe und ohne
- PT mit ROMBAR und ohne
- PT mit "allen Funktionen" und mit Funktionserweiterung ".0"
Bevor ich mit Live-Systemen arbeite: Hat noch jemand ein Problem mit Passthrough aktuell? Im Host läuft sie tadellos, auch für das PT ansich gibt es keine Fehlermeldung.
261.678119] ddbridge: Digital Devices PCIE bridge driver 0.9.33-integrated, Copyright (C) 2010-17 Digital Devices GmbH
261.722556] ddbridge 0000:01:00.0: detected Digital Devices MAX S8 4/8
261.722662] ddbridge 0000:01:00.0: HW 0201000f REGMAP 00010002
261.835619] ddbridge 0000:01:00.0: Port 0: Link 0, Link Port 0 (TAB 1): DUAL DVB-S2 MAX
261.835625] ddbridge 0000:01:00.0: Port 1: Link 0, Link Port 1 (TAB 2): DUAL DVB-S2 MAX
261.835629] ddbridge 0000:01:00.0: Port 2: Link 0, Link Port 2 (TAB 3): DUAL DVB-S2 MAX
261.835633] ddbridge 0000:01:00.0: Port 3: Link 0, Link Port 3 (TAB 4): DUAL DVB-S2 MAX
261.918136] dvbdev: DVB: registering new adapter (DDBridge)
261.918139] dvbdev: DVB: registering new adapter (DDBridge)
261.918140] dvbdev: DVB: registering new adapter (DDBridge)
261.918141] dvbdev: DVB: registering new adapter (DDBridge)
261.918142] dvbdev: DVB: registering new adapter (DDBridge)
261.918143] dvbdev: DVB: registering new adapter (DDBridge)
261.918144] dvbdev: DVB: registering new adapter (DDBridge)
261.918146] dvbdev: DVB: registering new adapter (DDBridge)
262.936464] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
263.030896] ddbridge 0000:01:00.0: DDBridge IRS 00000001
263.126597] i2c i2c-1: i2c read error 2
264.248493] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
264.341009] ddbridge 0000:01:00.0: DDBridge IRS 00000001
264.437084] i2c i2c-1: i2c read error 1
264.533793] i2c i2c-1: i2c read error 2
265.656453] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
265.748850] ddbridge 0000:01:00.0: DDBridge IRS 00000001
265.840858] i2c i2c-1: i2c read error 1
265.931738] i2c i2c-1: i2c read error 2
266.021025] ddbridge 0000:01:00.0: No MXL5XX found!
266.110240] ddbridge 0000:01:00.0: port_attach on port 0 failed
267.224450] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
267.307092] ddbridge 0000:01:00.0: DDBridge IRS 00000001
267.388142] i2c i2c-1: i2c read error 1
267.468397] i2c i2c-1: i2c read error 2
268.568471] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
268.648987] ddbridge 0000:01:00.0: DDBridge IRS 00000001
268.730521] i2c i2c-1: i2c read error 1
268.810312] i2c i2c-1: i2c read error 2
269.912493] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
269.992515] ddbridge 0000:01:00.0: DDBridge IRS 00000001
270.074354] i2c i2c-1: i2c read error 1
270.154111] i2c i2c-1: i2c read error 2
270.234855] ddbridge 0000:01:00.0: No MXL5XX found!
270.316024] ddbridge 0000:01:00.0: port_attach on port 1 failed
271.416416] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
271.495072] ddbridge 0000:01:00.0: DDBridge IRS 00000001
271.572985] i2c i2c-1: i2c read error 1
271.648662] i2c i2c-1: i2c read error 2
272.728436] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
272.799031] ddbridge 0000:01:00.0: DDBridge IRS 00000001
272.865130] i2c i2c-1: i2c read error 1
272.931514] i2c i2c-1: i2c read error 2
274.008407] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
274.077449] ddbridge 0000:01:00.0: DDBridge IRS 00000001
274.147100] i2c i2c-1: i2c read error 1
274.216795] i2c i2c-1: i2c read error 2
274.285227] ddbridge 0000:01:00.0: No MXL5XX found!
274.352358] ddbridge 0000:01:00.0: port_attach on port 2 failed
275.416389] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
275.479320] ddbridge 0000:01:00.0: DDBridge IRS 00000001
275.540317] i2c i2c-1: i2c read error 1
275.601526] i2c i2c-1: i2c read error 2
276.664375] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
276.664380] ddbridge 0000:01:00.0: DDBridge IRS 00000001
276.664385] i2c i2c-1: i2c read error 1
276.664386] i2c i2c-1: i2c read error 2
277.688345] ddbridge 0000:01:00.0: I2C timeout, card 0, port 0, link 0
277.742288] ddbridge 0000:01:00.0: DDBridge IRS 00000001
277.793201] i2c i2c-1: i2c read error 1
277.846904] i2c i2c-1: i2c read error 2
277.899086] ddbridge 0000:01:00.0: No MXL5XX found!
277.951430] ddbridge 0000:01:00.0: port_attach on port 3 failed
278.004407] ddbridge 0000:01:00.0: All connected ports failed to initialise!
278.058760] ddbridge 0000:01:00.0: fail3
278.110530] ddbridge 0000:01:00.0: fail2
278.162907] ddbridge 0000:01:00.0: fail1
278.214852] ddbridge 0000:01:00.0: fail0
278.264452] ddbridge 0000:01:00.0: fail
278.326604] ddbridge: probe of 0000:01:00.0 failed with error -1
btw: Vollupdate auf PVE 6.0-4, kernel 5.0.15-1, also alles as-new-as-possible. Epyc-Server siehe Signatur.
Gast-VM ist Ubuntu 19.04 Server, up-to-date. Stock-Kernel, keine Modifikationen, frisch installiert.
Das Problem hatte ich mit meiner MAX 8 unter ESXi mit Linux Guest auch. Alle möglichen Sachen mit msi etc. im Treiber und den ESXi Einstellungen durchprobiert. Wollte einfach nicht funktionieren, daher hab ich es nach einer Weile aufgegeben. Passthrough in eine Windows VM ging aber ohne Probleme.
