For example my gluster network IP is 10.10.10.1/24 and the /etc/hosts entry is:
10.10.10.1 gluster1.localdomain gluster1
Then I did 'gluster volume replace-brick ovirt1:/gluster_bricks/data/data
gluster1:/gluster_bricks/data/data commit'
So you use a hostname that is resolved either by DNS or /etc/hosts to your desired IP.
In my case, the change was done after initial deployment.
Best Regards,
Strahil NikolovOn Oct 17, 2019 16:51, Jayme <jaymef(a)gmail.com> wrote:
Thanks for the info, but where does it get the new hostname from? Do I need to change
the actual server hostnames of my nodes? If I were to do that then the hosts would not be
accessible due to the fact that the gluster storage subnet is isolated.
I guess I'm confused about what gdeploy does during a new HCI deployment. I
understand that you are now suppose to use hostnames that resolve to the storage network
subnet in the first step and then specify FQDNs for management in the next step. Where do
the FQDNs actually get used?
Can someone confirm if the hostname of oVirt host nodes should as shown by the
"#hostname" command should resolve to IPs on the gluster storage network?
On Thu, Oct 17, 2019 at 10:40 AM Strahil <hunter86_bg(a)yahoo.com> wrote:
>
> The reset-brick and replace-brick affects only one brick and notifies the gluster
cluster that a new hostname:/brick_path is being used.
>
> Of course, you need a hostname that resolves to the IP that is on the storage
network.
>
> WARNING: Ensure that no heals are pending as the commands are wiping the brick and
data there is lost.
>
> Best Regards,
> Strahil Nikolov
>
> On Oct 17, 2019 15:28, Jayme <jaymef(a)gmail.com> wrote:
>>
>> What does the reset brick option do and is it safe to do this on a live system or
do all VMs need to be brought down first? How does resetting the brick fix the issue with
gluster peers using the server hostnames which are attached to IPs on the ovirtmanagement
network?
>>
>> On Thu, Oct 17, 2019 at 4:16 AM Sahina Bose <sabose(a)redhat.com> wrote:
>>>
>>>
>>>
>>> On Wed, Oct 16, 2019 at 8:38 PM Jayme <jaymef(a)gmail.com> wrote:
>>>>
>>>> Is there a way to fix this on a hci deployment which is already in
operation? I do have a separate gluster network which is chosen for migration and gluster
network but when I originally deployed I used just one set of host names which resolve to
management network subnet.
>>>
>>>
>>> You will need to change the interface that's used by the bricks. You can
do this by using the "Reset brick" option, once the gluster management network
is set correctly on the storage interface from ovirt-engine
>>>>
>>>>
>>>>
>>>> I appear to have a situation where gluster traffic may be going through
both networks in seeing what looks like gluster traffic on both the gluster interface and
ovirt management.
>>>>
>>>> On Wed, Oct 16, 2019 at 11:34 AM Stefano Stagnaro
<stefanos(a)prismatelecomtesting.com> wrote:
>>>>>
>>>>> Thank you Simone for the clarifications.
>>>>>
>>>>> I've redeployed with both management and storage FQDNs; now
everything seems to be in its place.
>>>>>
>>>>> I only have a couple of questions:
>>>>>
>>>>> 1) In the Gluster deployment Wizard, section 1 (Hosts) and 2
(Additional Hosts) are misleading; should be renamed in something like "Host
Configuration: Storage side" / "Host Configuration: Management side".
>>>>>
>>>>> 2) what is the real function of the "Gluster Network"
cluster traffic type? What it actually does?
>>>>>
>>>>> Thanks,
>>>>> Stefano.
>>>>> _______________________________________________
>>>>> Users mailing list -- users(a)ovirt.org
>>>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>>>> Privacy Statement:
https://www.ovirt.org/site/privacy-policy/