Hi, Daniel. You are completely right. Change your CPU Freq in DB is safe, an CPU overprovisioning will help you.
2017-07-21 14:57 GMT+07:00 <daniel.herrm...@zv.fraunhofer.de>: > Hi Dag, Hi Ivan, > > thanks to both of you for your reply. I would like to build on the > question of my colleague Christian. > > Can you elaborate what would happen if we’d just change the service > offering in the database? From my understanding the main problem is, that > during VM creation the old and slightly higher value of 1999MHz has been > used for resource calculation, while only 1995MHz will be freed again when > one of the existing VMs are destroyed. Is this correct, are there any other > potential implications? > > If this is the only implication, this could be “corrected” with a slightly > increased overprovisioning factor of the CPU resource. This might not be a > very elegant solution, but changing the service offering is a hard problem > as well, because we cannot easily reboot all VMs currently hosted by CS. > > Thanks and regards > Daniel > > Am 21.07.17, 09:51 schrieb "Dag Sonstebo" <dag.sonst...@shapeblue.com>: > > Hi Christian – my twopence worth – for the sake of 4Mhz the DB change > should be OK, it seems a bit overkill to create and replace all your > service offerings just to accommodate your new 1995MHz hardware. > > Regards, > Dag Sonstebo > Cloud Architect > ShapeBlue > > On 21/07/2017, 08:07, "Ivan Kudryavtsev" <kudryavtsev...@bw-sw.com> > wrote: > > Hi. You just have to restart all affected VMs after offering > change, > because running VMs only get new resources after restart. > > It might be better to configure CPU overprovisioning in case you > met system > limits. > > 21 июл. 2017 г. 13:59 пользователь <christian.niephaus@zv. > fraunhofer.de> > написал: > > > Hi Ivan, > > > > thanks für die quick reply. > > > > Would you mind elaborating somewhat further on the potential > implications. > > Can I avoid unfaire resource provisioning by modifiying all > existing > > service offerings equally, e.g. changing the CPU Speed of all > offering from > > 1999 to 1995 MHz? > > > > Cheers, > > Christian > > > > > On 21. Jul 2017, at 03:37, Ivan Kudryavtsev < > kudryavtsev...@bw-sw.com> > > wrote: > > > > > > Hi, you can actually do it thru DB, but it can lead to several > > > implications, like unfare resource provisioning. The better > way is just > > > delete the offering, create the new with the same name and > switch all VMs > > > either automatically or asking users. > > > > > > Have a good day. > > > > > > 21 июл. 2017 г. 2:55 ДП пользователь <christian.niephaus@zv. > > fraunhofer.de> > > > написал: > > > > > > Dear all, > > > > > > as there is no means to modify an existing Cloudstack Service > Offering > > > neither via Cloudstack API nor with the GUI, I’m wondering > what would > > > happen if the CPU speed of the service offerings is changed > directly in > > the > > > cloud DB (table service_offering). Does this have any impact > on existing > > > VMs? Would this be a valid way to modify an existing Service > Offering? > > > > > > We did some very brief test and it seem to work fine, but > before doing > > the > > > change in our production environment I’d like to know if > anyone else has > > > done something similar? > > > > > > The reason why I’m trying to do this is as follows: > > > In all our Service Offerings for user VMs we have set the CPU > Speed to > > 1999 > > > Mhz. Unfortunately, the CPUs of our most recent hosts only > provide 1995 > > > MHz, leading to the situation that no VM is deployed on these > servers as > > > the hosts do not have the proper cpu capability (speed 1995 is > provided > > but > > > 1999 is required). > > > > > > Cheers, Christian > > > > > > PS: We’re still on Cloudstack 4.5.1 > > > > > > > > dag.sonst...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London WC2N 4HSUK > @shapeblue > > > > > > -- With best regards, Ivan Kudryavtsev Bitworks Software, Ltd. Cell: +7-923-414-1515 WWW: http://bitworks.software/ <http://bw-sw.com/>
