Hello Yiping,
There is also such functionality as "affinity groups". You may
define group and all VMs from that group will be deployed "close to each
other". I don't know whether group could be hard-bounded to specific
cluster. Probably not, because all hard-links are considered to be bad.
Try to imagine -- what happens, if you have entire c1 down, but all
other clusters are up ? Should client get deny of service just because
it belongs to wrong domain? Think about your requirements. Why do you
need such complicated rules?
Vadim.
On 2015-10-20 09:11, Vadim Kimlaychuk wrote:
Hello Yiping,
There is also such functionality as "affinity groups". You may define
group and all VMs from that group will be deployed "close to each
other". I don't know whether group could be hard-bounded to specific
cluster. Probably not, because all hard-links are considered to be bad.
Try to imagine -- what happens, if you have entire c1 down, but all
other clusters are up ? Should client get deny of service just because
it belongs to wrong domain? Think about your requirements. Why do you
need such complicated rules?
Vadim.
On 2015-10-19 21:41, Yiping Zhang wrote:
Hi, all:
I am trying to work out the best way of deploying VM's onto a
dedicated cluster. Here is what my CloudStack setup looks like:
Domains: d1, d2, d3, d4
Clusters: c1 (dedicated to d1), c2 (not dedicated)
Currently, I am not using tags for hosts, storages, service offerings
at all.
When I login to domains d2/d3/d4, and create new VM's, they will go to
cluster c2. That's great as it is the intended results.
However, when I login to domain d1 and create new VM's, they can go to
either cluster c1 or c2, but I would like VM's only go to c1.
Is using host/storage tags and matching tags in service offering the
only way to achieve this goal ?
The reason I am reluctant to use tags is that leads to proliferation
of service offerings, as the resulting number of SO could grow
exponentially with the number of host/storage tags introduced.
Thanks,
Yiping
