Totally agree with Andrija. -Wei
On Thu, 12 Sep 2019 at 17:41, Andrija Panic <andrija.pa...@gmail.com> wrote: > Guys, > > My 2 cents: > > I've played with dynamically increasing CPU number and RAM memory size > across all 3 hypervisors (during my analysis of how currently cpu/ram > overprovisioning works, in order to see the feasibility of dynamic > overprovisioning i.e. do any changes (reductions in cpu/ram) that we > already do after the VM is stopped and started - this dynamic apply of > overprovisioning is not a subject atm, just mentioning it for sake of > completeness. > > Balloning driver is officially an abandoned project (I explicitly pinged an > RH engineer to confirm what they stated on the balooning driver home > page...), so dynamically scalling down ram for KVM is not possible to be > done in the graceful maner. That beings said, you can still just blindly > reduce amount of ram (and cause kernel panics and such). > > Atm, we support dynamic scalling UP only, for XS and VMware - idea is that > we support the same for KVM - to be able to change Compute Offering to a > bigger one, on the fly. > This is possible with minor changes in XML, ad Rohit stated already and a > simple call to libvirt (i..e.virsh). > > From my point of view, we are not considering any special use cases etc, we > simply want to allow upgrading Compute Offering on the fly. > > Does this makes sense, any feedback? > > Cheers > > > > On Thu, Sep 12, 2019, 02:16 Riepl, Gregor (SWISS TXT) < > gregor.ri...@swisstxt.ch> wrote: > > > > Just to add some context, this was awhile back that I tried it, > > > years. The idea was that we could just set max memory to some crazy > > > high number and then “unlock” just the amount in the offering, and > > > adjust on the fly. As mentioned I found it was trivial for VM users > > > to unlock the full amount and get a “free” upgrade, so it was > > > useless. There was also a non trivial amount of RAM overhead just > > > lost to support balloon, if I recall. > > > > IMHO, supporting full dynamic scaling included shrinkage has a limited > > number of use cases. If you want a workload to be dynamically scalable, > > it would usually be much better to look into horizontal scaling, i.e. > > deploying more instances as load increases. If your workload is too > > small to make horizontal scaling effective, you should probably ask > > yourself the question if you need scaling at all. > > > > Limiting scaling to memory increase only might have some merit and > > should be much easier to implement by means of memory hotplug > > emulation. Though, is it really worth the complexity when an offline > > upgrade would normally only cause a very short downtime (or none at all > > in a HA setup)? > > > > >
