Re: Dynamic scaling support for KVM
Totally agree with Andrija. -Wei On Thu, 12 Sep 2019 at 17:41, Andrija Panic 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)? > > > > >
Re: Dynamic scaling support for KVM
I agree with Andrija. Von meinem iPhone gesendet __ Sven Vogel Teamlead Platform EWERK DIGITAL GmbH Brühl 24, D-04109 Leipzig P +49 341 42649 - 99 F +49 341 42649 - 98 s.vo...@ewerk.com www.ewerk.com Geschäftsführer: Dr. Erik Wende, Hendrik Schubert, Frank Richter Registergericht: Leipzig HRB 9065 Zertifiziert nach: ISO/IEC 27001:2013 DIN EN ISO 9001:2015 DIN ISO/IEC 2-1:2011 EWERK-Blog | LinkedIn | Xing | Twitter | Facebook Auskünfte und Angebote per Mail sind freibleibend und unverbindlich. Disclaimer Privacy: Der Inhalt dieser E-Mail (einschließlich etwaiger beigefügter Dateien) ist vertraulich und nur für den Empfänger bestimmt. Sollten Sie nicht der bestimmungsgemäße Empfänger sein, ist Ihnen jegliche Offenlegung, Vervielfältigung, Weitergabe oder Nutzung des Inhalts untersagt. Bitte informieren Sie in diesem Fall unverzüglich den Absender und löschen Sie die E-Mail (einschließlich etwaiger beigefügter Dateien) von Ihrem System. Vielen Dank. The contents of this e-mail (including any attachments) are confidential and may be legally privileged. If you are not the intended recipient of this e-mail, any disclosure, copying, distribution or use of its contents is strictly prohibited, and you should please notify the sender immediately and then delete it (including any attachments) from your system. Thank you. > Am 12.09.2019 um 17:41 schrieb Andrija Panic : > > 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)? >> >>
Re: Dynamic scaling support for KVM
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)? > >
Re: Dynamic scaling support for KVM
> 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)?
