Search results

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)

This is true. As soon as you have applied a disk to a vm then the content of the storage shifts from 'none' to 'images' in which case the storage will show as available for 'images'

It is this feature: https://www.illumos.org/issues/1701 which can be found in this commit: https://github.com/openzfs/zfs/commit/1b939560be5c51deecf875af9dada9d094633bf7 But as the documentation states this feature will only be available for SSD's so if the pool does not contain SSD's this...

Another thing to take into consideration when choosing between (stripped) mirrors or (stripped) raidz[x] is the overhead in calculating parity for raidz[x] and especially when doing resilvering of the pool. Calculating parity tend to require a CPU with higher clock speeds since parity...

There is a reason why running different CPU models and generations is unsupported and uncertified on VmWare as well!

See this thread: https://forum.proxmox.com/threads/zfs-over-iscsi-network-ha.66137/

Use stackable switches and create a LACP with connections to more than one switch (obviously the storage box should likewise have connections to more than one switch) and you should be failure proof.

Why not LACP? If one nic fails the take-over will be instantaneously.

Yes, it uses the same migration features as any other supported storage in Proxmox. Replication is handled on the storage server, not by Proxmox. What to you mean by 'shared storage controller fails over to another controller'?

No.

I wrote the code ;-)

I cannot replicate it now. It was must likely a combination of a VM started with different versions of kernel and various packages which for some reason was not able to start again ;-(

Last working kernel: pve-kernel-5.3.13-3-pve:amd64 I will try installing this kernel and see if it fixes the problem.

Any news?