Hi Antonie,
To prevent ACS from trying to allocate new resources to a secondary
storage, you could set it to read-only using the `updateImageStore` API.
As an alternative, you could use secondary storage selectors, through
the `createSecondaryStorageSelector` API, to prevent allocating
resources to one of your secondary storages. Secondary storage selectors
are a feature that allows you to set activation rules, written in
JavaScript, to determine which secondary storage will be selected to
allocate a resource. A selector is always related to a zone and a
resource (ISO, SNAPSHOT, TEMPLATE or VOLUME) and only one selector for
each resource is allowed in a zone. Activation rules must return the
secondary storage pool UUID that the resource will be allocated to, and
some variables are available to use in the rule, containing information
about the secondary storages, the resource being allocated and the
account allocating that resource.
Adding a selector with a rule such as the following will prevent
allocating resources in a single secondary storage:
```
function ignoreSecondaryStorage(pool) {
return pool.id !== '<ignored-secondary-storage-uuid>';
}
function randIndex(length) {
return Math.floor(Math.random() * length);
}
var idx = randIndex(secondaryStorages.length - 1);
secondaryStorages.filter(ignoreSecondaryStorage)[idx].id
```
A selector using this rule will prevent a secondary storage from being
selected for storing the resource, selecting another random pool.
Even though these methods can be used to prevent new resources from
being allocated in a secondary storage, there is currently no API that
can be used to prevent ACS from trying to read data from it;
furthermore, there is currently no API to force delete a secondary
storage. As a last resort, the resources in that storage could be
removed manually, setting them as removed through metadata changes
directly in the database, although this operation is risky and may
create more inconsistencies. If you do this, I highly recommend you
create a backup from the databases and do this in a staging environment
before applying any changes to a productive environment.
Regards,
Matheus Roque
On 2025/08/22 10:59:52 Antoine Boucher wrote:
> Hello,
>
> We utilise multiple secondary storage systems primarily for
resilience and scalability.
>
> However, when one of the secondary storage units fails, it becomes
very difficult to continue taking snapshots and adding new templates.
Given that the snapshots and templates on the failed server are
unavailable, is there a way to instruct ACS to ignore the failed storage
and proceed with the operational ones to maintain normal operation?
>
>
> Thank you,
> Antoine
>
>
>
>
