Search results

Use ip_hash as distribution algorithm. See: http://nginx.org/en/docs/http/load_balancing.html (Session persistence)

A bit flip on the disk/storage some time in the future cannot be detected at a specific point in time but must be detected on a regularly basis.

The solution to your problems is to enable sticky sessions. Your problem is that your novnc some times makes connection to another node than the one you are currently connected to.

Still with 8k zvol block size?

For zfs the safest and also given best performance is 'nocache'. This also implies the pool setting sync=standard

I find your tone very rude and insulting:(

No, if the disk(s) for l2arc and zil are not comparably faster than the disk(s) used in the pool you gain nothing but loosing ram over all.

This setup will never work since it is all about majority vote and with 4 nodes you can only lose one node. In your setup you will always loose at least two nodes which will cause the remaining node to change status to read-only effectively meaning a broken cluster. Cluster algorithm...

You should write OpenZFS. Most of the listed companies does not use zol but Solaris/Illumos or FreeBSD.

open the conf file for the vm found under /etc/pve/qemu-server and delete the line 'template: 1'.

Read here: https://askubuntu.com/questions/481414/install-nvidia-driver-instead-nouveau

According to the article he used defaults for all file systems which means compression was not enabled. Had compression been enabled I bet the numbers for zfs would have shown an increase of the performance by 20-30% (my experience).

I know it is two years old but I think the relative difference in performance is still the same in 2017 - which means except for btrfs all seems more or less equal so this boils down to make your choice vis-a-vis the features you think is important to your usecase.

Hi all, An interesting article can be read here: http://www.ilsistemista.net/index.php/virtualization/47-zfs-btrfs-xfs-ext4-and-lvm-with-kvm-a-storage-performance-comparison.html It compares performance between various file systems and combo of file systems + volume managers used as storage...

If trim is not supported the used blocks on a sparse volume will only grow since blocks previously allocated in the vm will never be released because the instruction to release these blocks from the vm cannot be honored by zol due to lacking support for trim.

Go to the resources tab and double-click on Cores: Cores: Number of cores wanted CPU limit: 0 (unlimited) <-- This is default setting CPU units: 1024 <-- This is default setting

I think I have solved the problem: Not working lxc which is created long time ago: arch: amd64 cpulimit: 1 cpuunits: 1024 hostname: deb-test memory: 512 net0: name=eth0,bridge=vmbr1000,hwaddr=3A:66:32:39:38:65,ip=dhcp,type=veth ostype: debian rootfs: omnios_nfs:106/vm-106-disk-2.raw,size=8G...

Same problem here on latest pve4.4: proxmox-ve: 4.4-92 (running kernel: 4.4.67-1-pve) pve-manager: 4.4-15 (running version: 4.4-15/7599e35a) pve-kernel-4.4.67-1-pve: 4.4.67-92 pve-kernel-4.4.62-1-pve: 4.4.62-88 lvm2: 2.02.116-pve3 corosync-pve: 2.4.2-2~pve4+1 libqb0: 1.0.1-1 pve-cluster: 4.0-52...

Well, no support for trim more or less makes thin provision useless.

But still no trim support:(