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.nieph...@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
