Search results

The disk format must be Qcow2 to be able to take snapshots and you have probably chosen raw.

Only if you install and configure multipathd

If the disk is in raw format you could use a loop mount and for qcow2 you must use qemu-nbd: see https://www.linuxunbound.com/2016/07/mounting-raw-and-qcow2-images/

I did not recommend that CPU it was just used to emphasize my point ;-). For 12 VM's I would go for a cpu with at least 6 cores.

Depended on usecase the usual recommendation is that the number of cores is more important than the max clock speed of the cores. This is the CPU used at DigitalOcean: Intel(R) Xeon(R) CPU E5-2650 v4 @ 2.20GHz. 12 cores and 24 threads. Another option to take into consideration is TDP.

If OP uses one of the supported LTS versions TRIM is not disabled so if that is the case then it must be another problem.

Or stop using btrfs which is unsupported in proxmox. If you insists on using btrfs avoid its raid5 or raid6 as the plague since it is unstable and has been for years. Read more here: https://forum.proxmox.com/threads/proxmox-with-zfs-or-btrfs.50962/

Are you referring to this line? Memory: 3960588K/4193764K available (14339K kernel code, 2370K rwdata, 4684K rodata, 2660K init, 5076K bss, 233176K reserved, 0K cma-reserved) Looking at that line I cannot make that be 4 GiB? Using free with default (free) shows total memory as 4030596 KiB...

Hi all, According to the GUI memory sizes should be in GiB (GibiBytes) but seems to actually be in GB (GigaBytes)? It is correct for disks (GiB as in GibiBytes) pve manager: 5.4-13 I have and example: /etc/pve/qemu-server/128.conf agent: 1 balloon: 2048 bootdisk: scsi0 cores: 2 cpu...

No, nothing in particular just a general observation.

If you want performance as in IO the only way to go is using RAID 10 (striped mirrors). More stripes means higher performance. The explanation given here is very god: https://www.youtube.com/watch?v=GuUh3bkzaKE

My impression is also that linux bridge is the stable and simple choice but with fewer features than ovs. Whether linux bridge or ovs is simpler to configure is a matter of taste ;-) Looking forward to see the result of your test. A comparison of cpu usage order load could be interesting too?

Anybody here aware of performance comparison tests made lately between openvswitch and linux bridge?

Just choose other disks for system under installation. After installation you can create your data pool on your disks assigned for that purpose.

The most obvious reason to your bad performance is that you use ZFS against recommendation. A ZFS filesystem should always be made of hole disks and not partitions. I would add another disk for system and boot partition and then recreate the ZFS filesystem on the 4 hole disks.

Try changing netmtu to see whether this fixes your problem. Default for netmtu is 1500.

corosync-qdevice is on version 3.0.0-4 in Debian Buster for ARM, so a simple upgrade of your PI to Debian Buster as well as with your PVE nodes and the issues should be solved. PS. corosync-qdevice-3.0.0-4 is backwards compatible with the corosync-2.x so you can upgrade your PI to Buster before...

Proxmox 6 should be available soon. Debian Buster ships 6. July 2019: https://lists.debian.org/debian-devel-announce/2019/06/msg00003.html

Except if you specify command interpreter on the command line like: perl ./test bash some_bash_script

This is an Ubuntu bug only. Debian does not use LXD.