You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Bharat Kumar <bh...@citrix.com> on 2013/02/12 10:27:55 UTC
Regarding cpu and ram overcommit feature
Hi all,
As a part of this feature we need to implement a method to update the overcommit ratios.
when we update the overcommit ratios all the Vms in the cluster need to be reconfigured as per the new values.
In order to do this i need to send some commands to the hypervisor and would like this operation to be asynchronous.
There are two ways to do this
1. ) To use the existing updateCluster Api
2.) Implement a new api
The problems with 1 are that it is synchronous command and making it asynchronous will break the backward compatibility and
in case of 2 we need to add a new api to change the overcommit ratios ( a cluster attribute ) which I think is not intuitive.
Please suggest a way to implement this.
Thanks.
Bharat.
Re: Regarding cpu and ram overcommit feature
Posted by Bharat Kumar <bh...@citrix.com>.
Well i think it is not about the advantage or disadvantage of doing this, it is only about the use case we want to support.
The use case which we are trying to support requires this.
Bharat.
On Feb 12, 2013, at 6:58 PM, Nitin Mehta <Ni...@citrix.com> wrote:
> What is the down side if we do not update the overcommit ratios on
> existing vms ?
> I don¹t see these ratios being changed quite often in the cloud.
>
> On 12/02/13 2:57 PM, "Bharat Kumar" <bh...@citrix.com> wrote:
>
>> Hi all,
>>
>> As a part of this feature we need to implement a method to update the
>> overcommit ratios.
>>
>> when we update the overcommit ratios all the Vms in the cluster need to
>> be reconfigured as per the new values.
>>
>> In order to do this i need to send some commands to the hypervisor and
>> would like this operation to be asynchronous.
>>
>> There are two ways to do this
>> 1. ) To use the existing updateCluster Api
>> 2.) Implement a new api
>>
>> The problems with 1 are that it is synchronous command and making it
>> asynchronous will break the backward compatibility and
>> in case of 2 we need to add a new api to change the overcommit ratios (
>> a cluster attribute ) which I think is not intuitive.
>>
>> Please suggest a way to implement this.
>>
>> Thanks.
>> Bharat.
>
Re: Regarding cpu and ram overcommit feature
Posted by Nitin Mehta <Ni...@citrix.com>.
What is the down side if we do not update the overcommit ratios on
existing vms ?
I don¹t see these ratios being changed quite often in the cloud.
On 12/02/13 2:57 PM, "Bharat Kumar" <bh...@citrix.com> wrote:
>Hi all,
>
>As a part of this feature we need to implement a method to update the
>overcommit ratios.
>
>when we update the overcommit ratios all the Vms in the cluster need to
>be reconfigured as per the new values.
>
>In order to do this i need to send some commands to the hypervisor and
>would like this operation to be asynchronous.
>
>There are two ways to do this
>1. ) To use the existing updateCluster Api
>2.) Implement a new api
>
>The problems with 1 are that it is synchronous command and making it
>asynchronous will break the backward compatibility and
> in case of 2 we need to add a new api to change the overcommit ratios (
>a cluster attribute ) which I think is not intuitive.
>
>Please suggest a way to implement this.
>
>Thanks.
>Bharat.
Re: Regarding cpu and ram overcommit feature
Posted by Chiradeep Vittal <Ch...@citrix.com>.
How about a new API updateClusterAsync?
OTOH, this is an admin API and it may not be as important to make this
asynchronous. Are there any other admin APIs that are asynchronous?
On 2/12/13 1:27 AM, "Bharat Kumar" <bh...@citrix.com> wrote:
>Hi all,
>
>As a part of this feature we need to implement a method to update the
>overcommit ratios.
>
>when we update the overcommit ratios all the Vms in the cluster need to
>be reconfigured as per the new values.
>
>In order to do this i need to send some commands to the hypervisor and
>would like this operation to be asynchronous.
>
>There are two ways to do this
>1. ) To use the existing updateCluster Api
>2.) Implement a new api
>
>The problems with 1 are that it is synchronous command and making it
>asynchronous will break the backward compatibility and
> in case of 2 we need to add a new api to change the overcommit ratios (
>a cluster attribute ) which I think is not intuitive.
>
>Please suggest a way to implement this.
>
>Thanks.
>Bharat.