Search results

Depends on your switch. We're using far more then 4 nodes with unicast without any problems here in HA mode.

Thanks for your suggestions and the numbers. Reusing the connection is indeed much better. So I stand corrected. Using the API directly (e.g. with proxmoxer) would be totally possible for the task at hand. :)

Could you please elaborate on how to fetch hundreds of VM configs a timely manner using the current HTTP-API? We haven't found a way to do that. So for the time until we have developed a proper patch for extending the API for a clusterwide VM config endpoint, we read the config directly from...

The PVE config files. VM configs, storage configs.

Yes, as I said, pvesh is not faster than using the API directly. As I read my post again, I notice that I missed to make the point why we decided to use pvesh and not the API directly. Since we access the files directly it is necessary to run the tool on a node of the cluster itself. Because of...

Yes, using the REST-API would be a good approach so it could be used from anywhere. However, there are some drawbacks with the API. The API is quite slow and for some information it is necessary to send multiple requests, like config details of all VMs. This scales very badly and quickly gets...

Hi, we've built a helper tool for PVE clusters called vman which comes with useful functions which PVE is missing, for example: * auto balance VMs in a PVE cluster depending on used and free memory * flushing an entire PVE node (i.e. for updates/reboots) * flushing only HA VMs (for updates)...

Yes, should work. You can try "grub-mkdevicemap" to make sure.

We also faced this issue a few times in the past. A good solution would be to have a "disable HA" (and fencing) button or CLI function for upgrade purposes. You can migrate all VMs managed by HA away from that node to avoid fencing before upgrading, if possible.

Thats the best solution, indeed. But we have some clusters with mixed "HA" and "non HA" VMs where it's not possible to migrate all VMs due to the lack of free RAM on the other node(s) ;) So we only do migrate the HA VMs before upgrading the PVE packages, which works just fine.

With active VMs "managed by HA".

We've always set "nofailback", but this still triggers fencing when updating a node with active HA resources afaik.

You could migrate VMs managed by HA to another node and then do the upgrade. Then no reboot will be applied. Your 2) is a good point imho, would be nice to have kind of a maintenance mode in the GUI which disabled HA.

Hint: You have to restart VMs after upgrading ceph librbd. so that they use new lib, if you want so set tunables to jewel or optimal on your ceph cluster. If you have a HA cluster then a migration should also work as there a new KVM process is spawned afaik.

Maybe you have to change /etc/fstab and GRUB Config, because virtoi uses "/dev/vda" and virto-scsi "/dev/sda".

Works also with SATA, if you use QCOW2 or LVM. You have to enable "discard" in the VM config and use virtio scsi as controller for VM. See also https://pve.proxmox.com/wiki/Qemu_trim/discard_and_virtio_scsi

Yes, you could even use a SSD designed for mixed or read intense enviroments (i.e. Samsung PM863).

You can't afaik - do you user LVM thin? You can try use ionice and nice to the vma and lzo process directly.

Works without problems here. The P440 works fine with hpsa driver out of the box.

Thats right afaik.