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)?
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. 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 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 > 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 >> Sent: Wednesday, September 11, 2019 2:11:22 PM >> To: dev >> 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 >> wrote: >> >> > I hope this features is implemented in near future. >> > >> > Regards >> > >> > On Wed, Sep 11, 2019 at 11:53 PM Rohit Yadav > > >> > 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: >> > > 8392704 >> > > 4194304 >> > > 4 >> > > >> > > Then, using virsh I could dynamically scale/up/down the vcpus and >> memory: >> > > virsh setmem 6G >> > > virsh setvcpus 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 >> > >
Re: Dynamic scaling support for KVM
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 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 > Sent: Wednesday, September 11, 2019 2:11:22 PM > To: dev > 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 > wrote: > > > I hope this features is implemented in near future. > > > > Regards > > > > On Wed, Sep 11, 2019 at 11:53 PM Rohit Yadav > > 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: > > > 8392704 > > > 4194304 > > > 4 > > > > > > Then, using virsh I could dynamically scale/up/down the vcpus and > memory: > > > virsh setmem 6G > > > virsh setvcpus 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 > > > Sent: Thursday, August 15, 2019 16:37 > > > To: dev@cloudstack.apache.org > > > Subject: Re: Dynamic scaling support for KVM > > > > > > +1 in 4.14. > > > > > > -Wei > > > > > > > > > > > > Fariborz Navidan 于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 > > > >
Re: Dynamic scaling support for KVM
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 Sent: Wednesday, September 11, 2019 2:11:22 PM To: dev 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 wrote: > I hope this features is implemented in near future. > > Regards > > On Wed, Sep 11, 2019 at 11:53 PM Rohit Yadav > 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: > > 8392704 > > 4194304 > > 4 > > > > Then, using virsh I could dynamically scale/up/down the vcpus and memory: > > virsh setmem 6G > > virsh setvcpus 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 > > Sent: Thursday, August 15, 2019 16:37 > > To: dev@cloudstack.apache.org > > Subject: Re: Dynamic scaling support for KVM > > > > +1 in 4.14. > > > > -Wei > > > > > > > > Fariborz Navidan 于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
Re: Dynamic scaling support for KVM
I've created a work-in-progress PR for this: https://github.com/apache/cloudstack/pull/3595 Regards, Nicolas Vazquez From: Andrija Panic Sent: Wednesday, September 11, 2019 6:11 PM To: dev 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 wrote: > I hope this features is implemented in near future. > > Regards > > On Wed, Sep 11, 2019 at 11:53 PM Rohit Yadav > 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: > > 8392704 > > 4194304 > > 4 > > > > Then, using virsh I could dynamically scale/up/down the vcpus and memory: > > virsh setmem 6G > > virsh setvcpus 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 > > Sent: Thursday, August 15, 2019 16:37 > > To: dev@cloudstack.apache.org > > Subject: Re: Dynamic scaling support for KVM > > > > +1 in 4.14. > > > > -Wei > > > > > > > > Fariborz Navidan 于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ć nicolas.vazq...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue
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 wrote: > I hope this features is implemented in near future. > > Regards > > On Wed, Sep 11, 2019 at 11:53 PM Rohit Yadav > 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: > > 8392704 > > 4194304 > > 4 > > > > Then, using virsh I could dynamically scale/up/down the vcpus and memory: > > virsh setmem 6G > > virsh setvcpus 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 > > Sent: Thursday, August 15, 2019 16:37 > > To: dev@cloudstack.apache.org > > Subject: Re: Dynamic scaling support for KVM > > > > +1 in 4.14. > > > > -Wei > > > > > > > > Fariborz Navidan 于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 > > Amadeus House, Floral Street, London WC2E 9DPUK > > @shapeblue > > > > > > > > > -- Andrija Panić
Re: Dynamic scaling support for KVM
I hope this features is implemented in near future. Regards On Wed, Sep 11, 2019 at 11:53 PM Rohit Yadav 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: > 8392704 > 4194304 > 4 > > Then, using virsh I could dynamically scale/up/down the vcpus and memory: > virsh setmem 6G > virsh setvcpus 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 > Sent: Thursday, August 15, 2019 16:37 > To: dev@cloudstack.apache.org > Subject: Re: Dynamic scaling support for KVM > > +1 in 4.14. > > -Wei > > > > Fariborz Navidan 于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 > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > > >
Re: Dynamic scaling support for KVM
I tried this: The domain XML needs to say what is the current allocation of vcpus or memory and what is the max. value: 8392704 4194304 4 Then, using virsh I could dynamically scale/up/down the vcpus and memory: virsh setmem 6G virsh setvcpus 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 Sent: Thursday, August 15, 2019 16:37 To: dev@cloudstack.apache.org Subject: Re: Dynamic scaling support for KVM +1 in 4.14. -Wei Fariborz Navidan 于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 Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue
Re: Dynamic scaling support for KVM
+1 in 4.14. -Wei Fariborz Navidan 于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 >
Re: Re:Re: Dynamic scaling support for KVM
+1 to the feature. Regards, Pavan. From: Haijiao <18602198...@163.com> Sent: 09 August 2019 11:02:27 To: dev@cloudstack.apache.org Subject: Re:Re: Dynamic scaling support for KVM +1, almost a 'must-have' feature in nowdays. At 2019-08-09 00:40:57, "Sven Vogel" wrote: >+1 from me too. I hope so with refactor or without :) > >Von meinem iPhone gesendet > > >__ > >Sven Vogel >Teamlead Platform > >EWERK RZ GmbH >Brühl 24, D-04109 Leipzig >P +49 341 42649 - 11 >F +49 341 42649 - 18 >s.vo...@ewerk.com >www.ewerk.com<http://www.ewerk.com> > >Geschäftsführer: >Dr. Erik Wende, Hendrik Schubert, Frank Richter >Registergericht: Leipzig HRB 17023 > >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 08.08.2019 um 18:18 schrieb Anurag Awasthi : >> >> +1 to the feature. >> >> @Fariborz, perhaps open a github issue as a new feature request? >> >> From: Simon Weller >> Sent: Thursday, August 8, 2019 6:30 PM >> To: dev@cloudstack.apache.org >> Subject: Re: Dynamic scaling support for KVM >> >> Hi Fariboz, >> >> We'd definitely like to add that functionality, but it's going to be a >> fairly big lift, as the libxml configs are currently built as a single >> block. A large refactor of how we interact with libvirt will be required. >> This is definitely something we have on our list and hopefully we can >> starting taking a look at it within the next few months. >> >> -Si >> ____ >> From: Fariborz Navidan >> Sent: Thursday, August 8, 2019 7:27 AM >> To: dev@cloudstack.apache.org >> Subject: Dynamic scaling support for KVM >> >> 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 >> >> anurag.awas...@shapeblue.com >> www.shapeblue.com<http://www.shapeblue.com> >> Amadeus House, Floral Street, London WC2E 9DPUK >> @shapeblue >> >> >> DISCLAIMER == This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails.
Re:Re: Dynamic scaling support for KVM
+1, almost a 'must-have' feature in nowdays. At 2019-08-09 00:40:57, "Sven Vogel" wrote: >+1 from me too. I hope so with refactor or without :) > >Von meinem iPhone gesendet > > >__ > >Sven Vogel >Teamlead Platform > >EWERK RZ GmbH >Brühl 24, D-04109 Leipzig >P +49 341 42649 - 11 >F +49 341 42649 - 18 >s.vo...@ewerk.com >www.ewerk.com > >Geschäftsführer: >Dr. Erik Wende, Hendrik Schubert, Frank Richter >Registergericht: Leipzig HRB 17023 > >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 08.08.2019 um 18:18 schrieb Anurag Awasthi : >> >> +1 to the feature. >> >> @Fariborz, perhaps open a github issue as a new feature request? >> ____ >> From: Simon Weller >> Sent: Thursday, August 8, 2019 6:30 PM >> To: dev@cloudstack.apache.org >> Subject: Re: Dynamic scaling support for KVM >> >> Hi Fariboz, >> >> We'd definitely like to add that functionality, but it's going to be a >> fairly big lift, as the libxml configs are currently built as a single >> block. A large refactor of how we interact with libvirt will be required. >> This is definitely something we have on our list and hopefully we can >> starting taking a look at it within the next few months. >> >> -Si >> >> From: Fariborz Navidan >> Sent: Thursday, August 8, 2019 7:27 AM >> To: dev@cloudstack.apache.org >> Subject: Dynamic scaling support for KVM >> >> 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 >> >> anurag.awas...@shapeblue.com >> www.shapeblue.com >> Amadeus House, Floral Street, London WC2E 9DPUK >> @shapeblue >> >> >>
Re: Dynamic scaling support for KVM
+1 from me too. I hope so with refactor or without :) Von meinem iPhone gesendet __ Sven Vogel Teamlead Platform EWERK RZ GmbH Brühl 24, D-04109 Leipzig P +49 341 42649 - 11 F +49 341 42649 - 18 s.vo...@ewerk.com www.ewerk.com Geschäftsführer: Dr. Erik Wende, Hendrik Schubert, Frank Richter Registergericht: Leipzig HRB 17023 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 08.08.2019 um 18:18 schrieb Anurag Awasthi : > > +1 to the feature. > > @Fariborz, perhaps open a github issue as a new feature request? > > From: Simon Weller > Sent: Thursday, August 8, 2019 6:30 PM > To: dev@cloudstack.apache.org > Subject: Re: Dynamic scaling support for KVM > > Hi Fariboz, > > We'd definitely like to add that functionality, but it's going to be a fairly > big lift, as the libxml configs are currently built as a single block. A > large refactor of how we interact with libvirt will be required. > This is definitely something we have on our list and hopefully we can > starting taking a look at it within the next few months. > > -Si > > From: Fariborz Navidan > Sent: Thursday, August 8, 2019 7:27 AM > To: dev@cloudstack.apache.org > Subject: Dynamic scaling support for KVM > > 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 > > anurag.awas...@shapeblue.com > www.shapeblue.com > Amadeus House, Floral Street, London WC2E 9DPUK > @shapeblue > > >
Re: Dynamic scaling support for KVM
+1 to the feature. @Fariborz, perhaps open a github issue as a new feature request? From: Simon Weller Sent: Thursday, August 8, 2019 6:30 PM To: dev@cloudstack.apache.org Subject: Re: Dynamic scaling support for KVM Hi Fariboz, We'd definitely like to add that functionality, but it's going to be a fairly big lift, as the libxml configs are currently built as a single block. A large refactor of how we interact with libvirt will be required. This is definitely something we have on our list and hopefully we can starting taking a look at it within the next few months. -Si From: Fariborz Navidan Sent: Thursday, August 8, 2019 7:27 AM To: dev@cloudstack.apache.org Subject: Dynamic scaling support for KVM 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 anurag.awas...@shapeblue.com www.shapeblue.com Amadeus House, Floral Street, London WC2E 9DPUK @shapeblue
Re: Dynamic scaling support for KVM
Hi Fariboz, We'd definitely like to add that functionality, but it's going to be a fairly big lift, as the libxml configs are currently built as a single block. A large refactor of how we interact with libvirt will be required. This is definitely something we have on our list and hopefully we can starting taking a look at it within the next few months. -Si From: Fariborz Navidan Sent: Thursday, August 8, 2019 7:27 AM To: dev@cloudstack.apache.org Subject: Dynamic scaling support for KVM 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
Dynamic scaling support for KVM
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
