I mean creating automatically via API or other mechanisms using api or how to easily distribute vm to all hosts ?
I had a similar question asked of me recently at work by a friend I hired to learn and help with IT related tasks...
His formulation of the question was something along the lines of: "So the cluster can distribute the load of a VM across the cluster, right?"
His formulation was of course, a bit more presumptive, but similar line of thinking. It's a valid question but stems from a bit of misunderstanding about how distributed computing works and the order of magnitude difference in latency and bandwidth available within a node vs on a network between nodes. Network bandwidth and latency sits in a similar "layer" of the memory hierarchy as disk access. This type of "access" can't be substituted for CPU socket/chiplet interlinks, RAM bus, or intra-CPU caching layers without a detrimental impact to performance.
A cluster of computers used for "distributed" computing, requires that the underlying workload be well suited for distribution and a mechanism for distributing the workload is developed and optimized per workload. There's no universal approach to distributed computing that could be applied at the hypervisor layer. This arrangement would have to take place as software running within each VM, talking to each-other.
If a single VM needs more access to computing resources, building more powerful nodes and assigning more computing resources to the VM is the most practical way to improve the server performance. If a workload can scale to multiple nodes effectively (either by a load balancing implementation that assigns incoming requests to a specific machine, or load bucket distribution mechanism), and development work has been done to implement the distribution/balancing mechanism, then the way to distribute the workload to multiple nodes in a proxmox cluster, is to run multiple VM's across multiple nodes, and configure their "internally optimized" load balance or compute distribution capability among them. This assures that latency sensitive aspects of the workload stay local, and distributed aspects are distributed or load balanced efficiently. The hypervisor is too "agnostic" to the workload to make these decisions for compute layer operations.
On the other hand, a software defined, distributed storage mechanism, works fine at the hypervisor layer, because storage is already the "bottom" of the memory access hierarchy in terms of speed/latency. Introducing a network distribution/replication aspect to this doesn't dramatically change the performance characteristic of the underlying drives (in some cases, it can actually improve it by adding additional buffering and/or striped read-mode).
