Open Stack

Greetings,
> probably I must use the same backend name for both  and a cinder type
associated to it and the scheduler will use the backend with more space
available ?
I'm not familiar with your deployment but there's a example in the
documentation that I think It may help you:

In a multiple-storage back-end configuration, each back end has a name (
volume_backend_name). Several back ends can have the same name. In that
case, the scheduler properly decides which back end the volume has to be
created in. i.e [1] In this configuration, lvmdriver-1 and lvmdriver-2 have
the same volume_backend_name. If a volume creation requests the LVM back
end name, the scheduler uses the capacity filter scheduler to choose the
most suitable driver, which is either lvmdriver-1 or lvmdriver-2. The
capacity filter scheduler is enabled by default. The next section provides
more information. In addition, this example presents a lvmdriver-3 back end.

Cheers,
Sofia
[1]
https://docs.openstack.org/cinder/xena/admin/blockstorage-multi-backend.html

On Thu, Nov 11, 2021 at 4:25 PM Ignazio Cassano <ignaziocassano at gmail.com>
wrote:

> Hello again, probably I must use the same backend name for both  and a
> cinder type associated to it and the scheduler will use the backend with
> more space available ?
> Ignazio
>
> Il Gio 11 Nov 2021, 20:00 Ignazio Cassano <ignaziocassano at gmail.com> ha
> scritto:
>
>> Hello All,
>> I read that capacity filters for cinder is the default, so, if I
>> understood well, a volume is placed on the backend where more space is
>> available.
>> Since my two backends are on storage with same features, I wonder if I
>> must specify a default storage backend in cinder.conf or not.
>> Must I create a cinder volume without cinder type and scheduler evaluate
>> where there is more space available?
>> Thanks
>> Ignazio
>>
>>
>>

-- 

Sofía Enriquez

she/her

Software Engineer

Red Hat PnT <https://www.redhat.com>

IRC: @enriquetaso
@RedHat <https://twitter.com/redhat>   Red Hat
<https://www.linkedin.com/company/red-hat>  Red Hat
<https://www.facebook.com/RedHatInc>
<https://www.redhat.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20211115/03dcf7fb/attachment.htm>