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(a)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]