Mailing-List: contact users-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@cloudstack.apache.org
Message-ID: <56DA81AE.3090106@gmail.com>
Date: Fri, 04 Mar 2016 22:50:22 -0800
From: ilya <ilya.mailing.lists@gmail.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11;
 rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: users@cloudstack.apache.org
Subject: Re: working with over provisioning factors
References: <534A43BD-F98F-467C-8A20-E847F9011F8E@marketo.com>
In-Reply-To: <534A43BD-F98F-467C-8A20-E847F9011F8E@marketo.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit

Yiping

I've done this before - several times in very large environments.

I'm not certain why you require a restart of VMs. Restart of VMs will
not reflect the change in cloudstack resources until you modify the DB.

If you want for mem.overprovisiong to take effect, you would need to
modify for each applicable VM-id in cloud.user_vm_details table.

This may be a bit painful for iterative SQL syntax to get correctly. I'd
suggest you do a db dump before hand.

Regards
ilya

PS: mem.overprovisiong - generally bad idea, but i'm certain you know
what works better for your environment.


On 3/2/16 4:56 PM, Yiping Zhang wrote:
> Hi,
> 
> I have to change the global and cluster setting memory.overprovisioning.factor for one of clusters with hundreds of running VM instances.  Now, in order for the changes to take effect, I need to restart all running instances.  I am wondering is there a way to update all running VM instances to reflect updated memory allocations without restarting every single VM instances?
> 
> While I am on the subject of restarting VM instances,  I went into data base to get their POWER_STATE_UPDATE_TIME value from vm_instance table directly. I noticed that this value is not consistently updated for those VM instances I restarted (either in UI or via API calls  with stop followed by start actions).  Is this a bug ?
> 
> Yiping
>