You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by ch...@zv.fraunhofer.de on 2017/07/20 19:54:30 UTC
Modifying a service offering in the cloudstack DB
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
Re: Modifying a service offering in the cloudstack DB
Posted by Ivan Kudryavtsev <ku...@bw-sw.com>.
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 <da...@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" <Da...@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" <ku...@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_ia@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.Sonstebo@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/>
Re: Modifying a service offering in the cloudstack DB
Posted by Dag Sonstebo <Da...@shapeblue.com>.
No problem, glad you got it sorted.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 24/07/2017, 10:30, "daniel.herrmann@zv.fraunhofer.de" <da...@zv.fraunhofer.de> wrote:
Hi Dag,
thanks again. We modified the DB last Friday and so far, this seems to work. We could move VMs to the new Hosts and new VMs are provisioned there as well.
Thank you again for your help.
Regards
Daniel
Am 21.07.17, 11:26 schrieb "Dag Sonstebo" <Da...@shapeblue.com>:
Hi Daniel,
Resource calculation will not be greatly affected by 4Mhz – you should be safe here. Keep in mind you are running with something like a 75% alert and 85% disable threshold on your clusters (see cluster settings / global settings) – and unless you increase the disable threshold to 100% you will never completely max out to the extent 4MHz will make a difference.
CPU overprovisioning is all about the overall amount of CPU resources available – not what speed each VM will receive.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 21/07/2017, 08:57, "daniel.herrmann@zv.fraunhofer.de" <da...@zv.fraunhofer.de> wrote:
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" <Da...@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" <ku...@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 пользователь <ch...@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 <ku...@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.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: Modifying a service offering in the cloudstack DB
Posted by da...@zv.fraunhofer.de.
Hi Dag,
thanks again. We modified the DB last Friday and so far, this seems to work. We could move VMs to the new Hosts and new VMs are provisioned there as well.
Thank you again for your help.
Regards
Daniel
Am 21.07.17, 11:26 schrieb "Dag Sonstebo" <Da...@shapeblue.com>:
Hi Daniel,
Resource calculation will not be greatly affected by 4Mhz – you should be safe here. Keep in mind you are running with something like a 75% alert and 85% disable threshold on your clusters (see cluster settings / global settings) – and unless you increase the disable threshold to 100% you will never completely max out to the extent 4MHz will make a difference.
CPU overprovisioning is all about the overall amount of CPU resources available – not what speed each VM will receive.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 21/07/2017, 08:57, "daniel.herrmann@zv.fraunhofer.de" <da...@zv.fraunhofer.de> wrote:
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" <Da...@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" <ku...@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 пользователь <ch...@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 <ku...@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.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: Modifying a service offering in the cloudstack DB
Posted by Dag Sonstebo <Da...@shapeblue.com>.
Hi Daniel,
Resource calculation will not be greatly affected by 4Mhz – you should be safe here. Keep in mind you are running with something like a 75% alert and 85% disable threshold on your clusters (see cluster settings / global settings) – and unless you increase the disable threshold to 100% you will never completely max out to the extent 4MHz will make a difference.
CPU overprovisioning is all about the overall amount of CPU resources available – not what speed each VM will receive.
Regards,
Dag Sonstebo
Cloud Architect
ShapeBlue
On 21/07/2017, 08:57, "daniel.herrmann@zv.fraunhofer.de" <da...@zv.fraunhofer.de> wrote:
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" <Da...@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" <ku...@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 пользователь <ch...@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 <ku...@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.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: Modifying a service offering in the cloudstack DB
Posted by da...@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" <Da...@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" <ku...@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 пользователь <ch...@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 <ku...@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.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: Modifying a service offering in the cloudstack DB
Posted by Dag Sonstebo <Da...@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" <ku...@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 пользователь <ch...@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 <ku...@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.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London WC2N 4HSUK
@shapeblue
Re: Modifying a service offering in the cloudstack DB
Posted by Ivan Kudryavtsev <ku...@bw-sw.com>.
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 пользователь <ch...@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 <ku...@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
>
>
Re: Modifying a service offering in the cloudstack DB
Posted by ch...@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 <ku...@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 ДП пользователь <ch...@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
Re: Modifying a service offering in the cloudstack DB
Posted by Ivan Kudryavtsev <ku...@bw-sw.com>.
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 ДП пользователь <ch...@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