Search results

not yet available, I'm targetting pve9.0. (we need some big other internal qemu block management change before it can be done)

pvesm set <storage> --options options vers=4.1,nconnect=8

10-20ms between both rooms ? with 20 servers nodes, it's seem quite huge for me to have a stable cluster. (and with nics around 60-80% , if you have some little spikes, it can hurt easily the cluster). https://pve.proxmox.com/wiki/Cluster_Manager#pvecm_cluster_network_requirements "The...

Personnally, If you use netapp, you should use nfs instead iscsi. (you'll have thinprovisioning and snasphots)

currently, it's possible that you are cpu limited, as 1disk in a vm can only use 1core for input/ouput. since qemu 9.0, it's possible to have multithreading to use multiple cores by disk, but it's not yet implemented in pve.

how do you test ? if you use iperf3, be carefull that it's not multithreaded (even if you use -P option for multiple streams), until you use a really really recent version of iperf3, so you could be cpu/core limited. (just do a top to verify). iperf2 is multithreaded if you want to compare

Hi, not yet implemented in proxmox, but https://docs.ceph.com/en/pacific/rbd/rbd-persistent-write-back-cache/ It's a local cache on the node where the vm is running

yes, snapshots on san are coming (with qcow2 on top of lvm, like ovirt indeed) . I'm working on it, I hope to finish it for pve9.

don't use zfs or ceph on consumer ssd/nvme without plp , performance will always be bad.

For this specific case, I think this is normal to have random slow ops error, as your pg and replicats can be on different slorage speed. (so, a primary write on fast sdd, will always wait for replicat on slow hdd), and for read, it's really russian roulette. (Personally, I'll do 2...

you have mixed ssd and hdd in the same pool ???

ok make sense. I'll try to see if we could implement it.

maybe you are cpu limited in the vm (currently 1disk can use only 1core with iothread). BTW, cache=writeback don't make too much sense with local nvme. It can even slowdown result. better to use cache=none.

the main reason is that current evpn implementation is done to use the anycast gateway distributed (and do l3rougint)on each node, but I'll not work if you use vlan behind. (Or maybe do you plan to use evpn to transport L2 only witout any routing ?)

https://pve.proxmox.com/wiki/Serial_Terminal#Add_a_virtual_serial_port_to_the_VM (then you can use the alternative xterm console, where copy/paste is working). but you can't have display, until you configure some config in the guest

xterm console allow copy paste, but you need to redirect output first to the serial. (maybe copy/paste could work blindly, no sure)

you should first restart pve-cluster service, to mount the /etc/pve directory . (it's used /var/lib/pve-cluster/config.db as backend, and expose it like a fs in /etc/pve)

mv /etc/pve/ha/resources.cfg /tmp/ ;) then move back the file again Note than you need to close watchdog too to avoid fencing, the currently only is it to 1) stop pve-ha-lrm on all nodes, node by node 2) stop pve-ha-crm on all nodes, node by node then, do the reverse when on have...

I have see some similar problem with migration from vmware, seem than rocky don't have virtio drivers by default in initramfs when it's deployed first on different hypervistor maybe try to boot with ide, then sudo dracut -f --regenerate-all --add-drivers "virtio_blk virtio_scsi virtio_net"...

shouldn't be a problem, but if you use HA, you really to disable it before.