public inbox for pve-devel@lists.proxmox.com
 help / color / mirror / Atom feed
From: "DERUMIER, Alexandre" <Alexandre.DERUMIER@groupe-cyllene.com>
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
	"Proxmox VE development discussion" <pve-devel@lists.proxmox.com>
Subject: Re: [pve-devel] proxmox French days conference feedback
Date: Wed, 24 Aug 2022 12:59:51 +0000	[thread overview]
Message-ID: <1de5c768-64a2-3777-baff-2b80279e91a7@groupe-cyllene.com> (raw)
In-Reply-To: <3ab98c32-e9d6-f37f-8e8c-858a1e6d0c86@proxmox.com>

Hi Thomas,

Sorry I totally miss your reponse !

>> - a drs feature like vmware for vm balancing
>> (I'm still working on it, I'll try to have a working after this summer.
>>   I still need vm pressure stats pending patches apply first 😉
> 
> I'd really like to more actively work on this from our part too, I thought about
> 7.3 feature planning a  bit yesterday and wrote a few (rough) edge points for
> tackling this, using the alogrithm and rough direction you already worked on in
> your proof of concepts (thx!):
> 
> - [ ] Static (and later Dynamic) Resource Scheduling (S/DRS)
>      - [ ] Coordinate with Alexandre as he's working partly on that too, but we
>            may want to use a bit of a different design and/or feature set (at
>            least initially) and integration timeline

I have free time to work/help on this in coming months, just tell me if 
we can sync work.

>      - [ ] checkout TOPSIS more closely and implement relevant parts in rust to
>            expose via perlmod, that's then fast and much easier to reason
>            correctness in static, and safety focused language like rust.

I can help if you have question to reimplement topsis in rust (I have 
done it from stratch in perl following the youtube math tutorial, it's 
not too difficult).

>      - [ ] Make basic static resource capacity like CPU (# of socket, core and
>            hyper threads) and memory available for other cluster nodes (for
>            example, via kv_broadcast after (re)start of pve-cluster)
>      - [ ] Add infrastructure to use that static (!) information for balancing
>            out the cluster.
>          - [ ] spit out a list of actions that would result in a balanced
>                cluster: migrate guest A to node X, migrate guest B to node Y
>          - [ ] use that for creating a simulation and regression testing system
>                in the spirit of the ha-managers simulation and regression test
>                system, but as independent test & executable
I think adding to user a manual balancing feature, with static/preview 
list of migration with manual approval could be great too

>      - [ ] integrate in HA, due to static-ness and safe-and-slow integration it
>            should be first only be done on recovery, for better balancing out.
>      - [ ] add API create support for creating a CT/VM to the best fitting node,
>            i.e., the lowest used one
yes, needed. (and also maybe start on the best fitting node)

>      - [ ] make balancing algo available for non-ha too, allow a cluster wide
>            manual re-balance (e.g., with action-proposal shown to user for
>            confirmation)
yes, some users already have asked me about the non-ha vm.

>      - [ ] Extend with dynamic information like IO/memory/CPU pressure

cpu pressure is really the most important here. Because you can't trust 
cpu usage. (I have some servers with 60% cpu usage totally overloaded, 
and other servers with 80% cpu usage not overloaded).

The main problem is that we have average value across all cores, and 
with a lot of cores, some cores can be stuck at 100%, other at 10%, this 
give you a low cpu usage. But if some vms need to use a lot of cores, 
they will be overloaded.

That's why in my code, I'm looking only for cpu pressure on source node,
and on the target node, I'm looking to  low cpu pressure + cpu usage 
under 80%.  (We can only trust cpu usage if cpu pressure is low)


>      - [ ] Finally: Allow to opt-in in periodic auto-balancing for HA managed
> 
> IMO the semi-static resource availability and usage would be nice in general as
> first step, that could then also allow one to relatively easily pre-error/warn out
> on VM start if there won't be enough memory available (maybe overridable for odd
> zram/KSM cases, or when one just doesn't want to care about that and likes OOMs ;)
> 


I have a lot of customers wanting to migrate from vmware with the 
broadcom acquisition, but the missing drs feature is really blocking for 
them.

If needed, we could also help to finance this feature, if you need extra 
developper.
Just ask me !








      reply	other threads:[~2022-08-24 13:00 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-23  8:43 DERUMIER, Alexandre
2022-06-23 10:59 ` Thomas Lamprecht
2022-08-24 12:59   ` DERUMIER, Alexandre [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1de5c768-64a2-3777-baff-2b80279e91a7@groupe-cyllene.com \
    --to=alexandre.derumier@groupe-cyllene.com \
    --cc=pve-devel@lists.proxmox.com \
    --cc=t.lamprecht@proxmox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Service provided by Proxmox Server Solutions GmbH | Privacy | Legal