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 <[email protected]> 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] > > _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
