cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yiping Zhang <>
Subject Re: storage affinity groups
Date Thu, 08 Sep 2016 23:55:18 GMT
Well, using tags leads to proliferation of templates or service offerings etc. It is not very
scalable and gets out of hand very quickly.


On 9/8/16, 4:25 PM, "Marty Godsey" <> wrote:

    I do this by using storage tags. As an example I have some templates that are either created
on SSD or magnetic storage. The template has a storage tag associated with it and then I assigned
the appropriate storage tag to the primary storage.
    Marty Godsey
    -----Original Message-----
    From: Tutkowski, Mike [] 
    Sent: Thursday, September 8, 2016 7:16 PM
    Subject: Re: storage affinity groups
    If one doesn't already exist, you can write a custom storage allocator to handle this
    > On Sep 8, 2016, at 4:25 PM, Yiping Zhang <> wrote:
    > Hi,  Devs:
    > We all know how (anti)-host affinity group works in CloudStack,  I am wondering if
there is a similar concept for (anti)-storage affinity group?
    > The use case is as this:  in a setup with just one (somewhat) unreliable primary
storage, if the primary storage is off line, then all VM instances would be impacted. Now
if we have two primary storage volumes for the cluster, then when one of them goes offline,
only half of VM instances would be impacted (assuming the VM instances are evenly distributed
between the two primary storage volumes).  Thus, the (anti)-storage affinity groups would
make sure that instance's disk volumes are distributed among available primary storage volumes
just like (anti)-host affinity groups would distribute instances among hosts.
    > Does anyone else see the benefits of anti-storage affinity groups?
    > Yiping

View raw message