Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-users@incubator.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 27 Dec 2012 21:29:56 +0800 (CST)
From: jerry =?utf-8?B?amlhbmcuIOiSi+e7tA==?= <jerry.jiang@tyxtech.com>
To: cloudstack-users@incubator.apache.org
Message-ID: <324391192.7982.1356614996843.JavaMail.root@tyxtech.com>
In-Reply-To: <479F3924-D457-4AE1-9A70-21ABE0F694C4@citrix.com>
Subject: Re: overcommit radio setting per-pod basis and restoring VMs if
 host failed
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

Hi Nithin

Thanks.
My comments inline.


----- Original Message -----
From: "Nitin Mehta" <Nitin.Mehta@citrix.com>
To: cloudstack-users@incubator.apache.org
Sent: Thursday, December 27, 2012 8:53:48 PM
Subject: Re: overcommit radio setting per-pod basis and restoring VMs if ho=
st failed

Answers inline

On 27-Dec-2012, at 5:58 PM, jerry jiang. =E8=92=8B=E7=BB=B4 wrote:

> hello,
>=20
> I have two questions regarding Cloudstack function,
>=20
> 1) How can I set different overcommit radio for different pod (or cluster=
) in one zone.

Currently this is not possible. But, there is a plan for this feature in th=
e upcoming release for setting it cluster based. If you don't mind, can you=
 please share your use case for setting it different for different pods ?

[jerry] I want this feature because I want to deploy two pods for different=
 department in my datacenter. One is for testing my Apps to verify its func=
tions, I would like this pod to support overcommit radio(120%) because func=
tion-testing won't consume much CPU resource. and another one is for testin=
g my Apps to verify performance, I would like this pod not to support under=
commit radio(80%) becasue it will guarentee the Apps to get resource as nee=
ded.


>=20
> 2) When I use CS to manage hosts, if one of host failed, can I restore th=
e VMs in the host via providing another healthy host?
>=20

While creating vm's you can use service offering which has HA (highly avail=
able) as true. If the host fails CS will automatically take care of migrati=
ng it to a healthy host within the cluster.
Let's say you didn't use that service offering while deploying the vm then =
if the host fails, these vms would go into stopped state. You can try start=
ing these vms and they should come up on a healthy host within the cluster.=
 I am assuming you are using shared storage here and would have enough capa=
city in the cluster.

[jerry] that means I can create VMs by API directly even if I didn't create=
 service offering, right? please comfirm.


> Thanks
>=20
> Jerry Jiang