Search results

For privacy reasons I use my own email server. Also relaying through another email server pose some difficulties on me since it will be difficult to register a mail address to the pve-devel list not matching the the email servers domain ;-)

Hi all, When I try to send email to the pve-devel list by mail is returned with the following response: <pve-devel@lists.proxmox.com>: host firstgate.proxmox.com[212.224.123.68] said: 550 5.7.1 Service unavailable; client [83.93.223.153] blocked using zen.spamhaus.org (in reply to RCPT...

This is entirely up to the host to deside. write-back cache is equivalent to a hardware raid controller.

This is dangerous since writes are written to memory and first latter persisted to storage.

With statements like this it is also obviously that you are new to Linux ;-)

Maybe you should consider using restic on-top of rclone to enforce security? https://github.com/restic/restic

I can recommend this place for help with hardware raid controllers: https://kb.open-e.com/19/ There is many articles about various problems and recommended settings for optimal performance in different use cases.

Well, in my opinion virtualization requires thin provision and snapshots either from the image format or from the storage solution and abstraction from the hardware. You can live with one of the features missing if your not using it in an enterprise environment but missing two features is more...

It seems to lack snapshot feature? If this is the case then it is a very limited virtualization storage solution.

You could create a cron job to run pveum realm sync "Realm"

In the servers BIOS there is a setting controlling the way the server behaves when power is lost and power is returned. Normally there are three settings: Start when power comes back (sounds like your case since the UPS supplies sufficient power), stay powered off, or return to the previous mode...

With a SAN there is no need for snapshot and thin provision since this can be done on the SAN side. And as a side note: When using a SAN you should do your storage administration on the SAN side using whatever tools/gui the SAN provides since the SAN knows way more about the storage than Proxmox.

What about option --threads=0..200? Any benchmarks performed adjusting the number of threds used? There is also this option which could reduce the archive size further and increase decompression time: --[no-]sparse

What output do you get from: ip l (l means letter l) And also what output does cat /etc/network/interfaces show

If Ceph profits considerably by low latency then network should be Infiniband since Infiniband has almost no latency whatsoever.

Something must be broken in the FreeNAS-API. Try asking the developer of the FreeNAS-API what is wrong. Using ZFS over iSCSI with Comstar works flawlessly here.

It seems a part of your lines in the screendump is chopped of? Try using systemctl status -l pve-container@106.service instead.

As always using this with fio gives you a comparable test: # This job file tries to mimic the Intel IOMeter File Server Access Pattern [global] description=Emulation of Intel IOmeter File Server Access Pattern [iometer] bssplit=512/10:1k/5:2k/5:4k/60:8k/2:16k/4:32k/4:64k/10 rw=randrw...

Looks like a go thing to make a feature request for on https://bugzilla.proxmox.com/

Not something I see here. Fedora privileged container 1 core (host has 8 cores) Debian unprivileged container 1 core (host has 8 cores)