[ovirt-users] Storage network clarification
Fil Di Noto
fdinoto at gmail.com
Tue Feb 2 00:59:56 UTC 2016
Thanks I will add those steps to my notes and try again some time in
the future. Trying to move storage network functions from ovirtmgmt to
a dedicated logical network for an existing gluster volume did not go
well for me. I did not put much effort into recovering, but I lost the
storage domain completely. I did not collect any logs because I was
pressed for time.
I am finding it easier to manage gluster outside of ovirt for now.
Without knowing how VDSM is going to try to approach a task it becomes
more time consuming (and sometimes destructive) to work with VDSM than
to just do things manually.
On Tue, Jan 19, 2016 at 12:44 AM, Sahina Bose <sabose at redhat.com> wrote:
>
>
> On 01/19/2016 12:37 PM, Nicolas Ecarnot wrote:
>>
>> Hi Sahina,
>>
>> Le 19/01/2016 07:02, Sahina Bose a écrit :
>>>
>>> The steps to make sure gluster uses separate network for data traffic :
>>>
>>> 1. Create a logical network (non-VM), and mark it's role as "Gluster"
>>> 2. After adding the host via the ovirtmgmt hostname/ ip address, assign
>>> this gluster network to your interface (with the storage sub-net)
>>> This step will initiate a peer probe of the host with this additonal
>>> ip address.
>>>
>>> 3. When creating a volume after an interface/bond is tagged with gluster
>>> network, the bricks are added using the gluster n/w's ip address. Now
>>> when clients connect to the volume, traffic is routed via your gluster
>>> network that's used by bricks.
>>
>>
>> Does that mean that there's no way to reach this goal with an existing
>> volume, previously created, and that was (alas) using the management
>> network?
>
>
>
> There's some ongoing work to replace network used by brick -
> http://review.gluster.org/#/c/12250/ and https://gerrit.ovirt.org/#/c/51685/
> [+Kaushal, Anuradha for further inputs and if there's any manual workaround
> possible]
>
>
More information about the Users
mailing list