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.
It’s possible balloon could be useful for some “trusted workload” situations, internal use, etc. however I have just gotten the impression over the years that not many are satisfied with ballooning in general. I’d be curious to understand the cpu autoscaling use cases. My first thought was that if you want a VM that will only use one core when idle and use eight or more cores when busy, it will already do that if you just size to max. Is there a scheduling/allocation/DRS angle here, or a cgroup/shares scaling angle, or something else? Maybe a billing angle, maybe we want to allow people to “give back” and only pay for a certain number of cores at any given moment, rather than doing a cpu util % billing model? I’ve heard of people wanting to spin up more instances based on load balancer data, but traditionally not much demand for shrinking/growing CPU and memory, except maybe in the DRS case where it is combined with being able to shuffle workloads across physical resources. On Wednesday, September 11, 2019, Marcus <shadow...@gmail.com> wrote: > Yes, it puts memory pressure within the VM to evict the memory and then it > is hidden from the OS. > > However, I’m not a fan of ballooning, as it depends on a driver in the > guest OS. When I tested it a few years back one simply had to blacklist the > module within the VM to get the full (max) RAM, as the driver’s job is to > hide the difference from the guest kernel. Therefore it wasn’t very useful > as a means of providing tiered offerings that could be changed on the fly. > > I haven’t played with this in awhile though, so perhaps we are > seeing/working toward true memory hotplug now. > > On Wednesday, September 11, 2019, Rohit Yadav <rohit.ya...@shapeblue.com> > wrote: > >> Hi Andrija, >> >> I tried scaling down memory, it worked on my test VM. I don't think it >> should cause VM or apps to crash if libvirt allows. >> >> Regards. >> >> Regards, >> Rohit Yadav >> >> ________________________________ >> From: Andrija Panic <andrija.pa...@gmail.com> >> Sent: Wednesday, September 11, 2019 2:11:22 PM >> To: dev <dev@cloudstack.apache.org> >> Subject: Re: Dynamic scaling support for KVM >> >> Correct Rohit - but we will not support scaling down the MEM (nor CPU), >> since OS will crash, since there is no working ballooning driver (you need >> to use ballooning device (check) and the driver inside OS - which is an >> abandoned project - I have pinged an RHEL engineer for this, and he >> explicitly confirmed). >> >> So same scale-up as we do with VMware and XenServer - very simple to >> implement I guess. One thing to notice, per my tresting (would be good to >> confirm) - balooning device is automatically injected in the XML of a VM >> when RAM overprovisioning factor is set (which hopefully no one will do) - >> so we just need to inject the balooning device perhaps in every VM - >> again, >> to be checked. >> >> On Wed, 11 Sep 2019 at 12:31, Fariborz Navidan <mdvlinqu...@gmail.com> >> wrote: >> >> > I hope this features is implemented in near future. >> > >> > Regards >> > >> > On Wed, Sep 11, 2019 at 11:53 PM Rohit Yadav <rohit.ya...@shapeblue.com >> > >> > wrote: >> > >> > > I tried this: >> > > >> > > The domain XML needs to say what is the current allocation of vcpus or >> > > memory and what is the max. value: >> > > <memory unit='KiB'>8392704</memory> >> > > <currentMemory unit='KiB'>4194304</currentMemory> >> > > <vcpu placement='static' current='2'>4</vcpu> >> > > >> > > Then, using virsh I could dynamically scale/up/down the vcpus and >> memory: >> > > virsh setmem <domain> 6G >> > > virsh setvcpus <domain> 4 >> > > >> > > This changed the value in domain XML for the currentMemory and current >> > > value in vcpu xml node. >> > > >> > > The current scaling feature allows changing a compute/service >> offering. >> > > Using virsh, we can set the max cpus and memory (using setmaxmem and >> > > setvcpus), so the implementation can run the equivalent in domain xml >> > edit >> > > while applying the changes comput offering. I don't think any change >> in >> > > offerings or db/schema is necessary. >> > > >> > > >> > > Regards, >> > > >> > > Rohit Yadav >> > > >> > > Software Architect, ShapeBlue >> > > >> > > https://www.shapeblue.com >> > > >> > > ________________________________ >> > > From: Wei ZHOU <ustcweiz...@gmail.com> >> > > Sent: Thursday, August 15, 2019 16:37 >> > > To: dev@cloudstack.apache.org <dev@cloudstack.apache.org> >> > > Subject: Re: Dynamic scaling support for KVM >> > > >> > > +1 in 4.14. >> > > >> > > -Wei >> > > >> > > >> > > >> > > Fariborz Navidan <mdvlinqu...@gmail.com> 于2019年8月8日周四 下午2:27写道： >> > > >> > > > Hello Devs, >> > > > >> > > > Since long time ago libvirt supports live horizental scaling of >> VMs. Do >> > > you >> > > > intend for ACS 4.13 to support dynamic scaling of KVM VMs? >> > > > >> > > > TIA >> > > > >> > > >> > > rohit.ya...@shapeblue.com >> > > www.shapeblue.com<http://www.shapeblue.com> >> > > Amadeus House, Floral Street, London WC2E 9DPUK >> > > @shapeblue >> > > >> > > >> > > >> > > >> > >> >> >> -- >> >> Andrija Panić >> >> rohit.ya...@shapeblue.com >> www.shapeblue.com >> Amadeus House, Floral Street, London WC2E 9DPUK >> @shapeblue >> >> >> >>
