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@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]