1:30 p.m.
This only started to happen with oVirt node 4.3, 4.2 didn't have issue. Since I
updated to 4.3, every reboot the host goes into emergency mode. First few times this
happened I re-installed O/S from scratch, but after some digging I found out that the
drives it mounts in /etc/fstab cause the problem, specifically these mounts. All three
are single drives, one is an SSD and the other 2 are individual NVME drives.
UUID=732f939c-f133-4e48-8dc8-c9d21dbc0853 /gluster_bricks/storage_nvme1 auto defaults 0 0
UUID=5bb67f61-9d14-4d0b-8aa4-ae3905276797 /gluster_bricks/storage_ssd auto defaults 0 0
UUID=f55082ca-1269-4477-9bf8-7190f1add9ef /gluster_bricks/storage_nvme2 auto defaults 0 0
In order to get the host to actually boot, I have to go to console, delete those mounts,
reboot, and then re-add them, and they end up with new UUIDs. all of these hosts reliably
rebooted in 4.2 and earlier, but all the versions of 4.3 have this same problem (I keep
updating to hope issue is fixed).
11:27 p.m.
Adding Sachi
On Thu, May 9, 2019 at 2:01 AM <michael(a)wanderingmad.com> wrote:
This only started to happen with oVirt node 4.3, 4.2 didn't have
issue.
Since I updated to 4.3, every reboot the host goes into emergency mode.
First few times this happened I re-installed O/S from scratch, but after
some digging I found out that the drives it mounts in /etc/fstab cause the
problem, specifically these mounts. All three are single drives, one is an
SSD and the other 2 are individual NVME drives.
UUID=732f939c-f133-4e48-8dc8-c9d21dbc0853 /gluster_bricks/storage_nvme1
auto defaults 0 0
UUID=5bb67f61-9d14-4d0b-8aa4-ae3905276797 /gluster_bricks/storage_ssd auto
defaults 0 0
UUID=f55082ca-1269-4477-9bf8-7190f1add9ef /gluster_bricks/storage_nvme2
auto defaults 0 0
In order to get the host to actually boot, I have to go to console, delete
those mounts, reboot, and then re-add them, and they end up with new
UUIDs. all of these hosts reliably rebooted in 4.2 and earlier, but all
the versions of 4.3 have this same problem (I keep updating to hope issue
is fixed).
_______________________________________________
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/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/I4UKZAWPQDX...
12:27 a.m.
On Mon, May 20, 2019 at 11:58 AM Sahina Bose <sabose(a)redhat.com> wrote:
Adding Sachi
On Thu, May 9, 2019 at 2:01 AM <michael(a)wanderingmad.com> wrote:
> This only started to happen with oVirt node 4.3, 4.2 didn't have issue.
> Since I updated to 4.3, every reboot the host goes into emergency mode.
> First few times this happened I re-installed O/S from scratch, but after
> some digging I found out that the drives it mounts in /etc/fstab cause the
> problem, specifically these mounts. All three are single drives, one is an
> SSD and the other 2 are individual NVME drives.
>
> UUID=732f939c-f133-4e48-8dc8-c9d21dbc0853 /gluster_bricks/storage_nvme1
> auto defaults 0 0
> UUID=5bb67f61-9d14-4d0b-8aa4-ae3905276797 /gluster_bricks/storage_ssd
> auto defaults 0 0
> UUID=f55082ca-1269-4477-9bf8-7190f1add9ef /gluster_bricks/storage_nvme2
> auto defaults 0 0
>
> In order to get the host to actually boot, I have to go to console,
> delete those mounts, reboot, and then re-add them, and they end up with new
> UUIDs. all of these hosts reliably rebooted in 4.2 and earlier, but all
> the versions of 4.3 have this same problem (I keep updating to hope issue
> is fixed).
>
Hello Michael,
I need your help in resolving this. I would like to understand if the
environment is
affecting something.
What is the out put of:
# blkid /dev/vgname/lvname
For the three bricks you have.
And also what is the error you see when you run the command
# mount /gluster_bricks/storage_nvme1
# mount /gluster_bricks/storage_ssd
Also can you please attach your variable file and playbook?
In my setup things work fine, which is making it difficult for me to fix.
-sac
12:42 p.m.
New subject: oVirt node loses gluster volume UUID after reboot, goes to emergency mode every time I reboot.
I'm sorry, i'm still working on my linux knowledge, here is the output of my blkid
on one of the servers:
/dev/nvme0n1: PTTYPE="dos"
/dev/nvme1n1: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020: PTTYPE="dos"
/dev/mapper/eui.0025385881b40f60: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020p1:
UUID="pfJiP3-HCgP-gCyQ-UIzT-akGk-vRpV-aySGZ2" TYPE="LVM2_member"
/dev/mapper/eui.0025385881b40f60p1:
UUID="Q0fyzN-9q0s-WDLe-r0IA-MFY0-tose-yzZeu2" TYPE="LVM2_member"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H: PTTYPE="dos"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H1:
UUID="lQrtPt-nx0u-P6Or-f2YW-sN2o-jK9I-gp7P2m" TYPE="LVM2_member"
/dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
UUID="890feffe-c11b-4c01-b839-a5906ab39ecb" TYPE="vdo"
/dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
UUID="7049fd2a-788d-44cb-9dc5-7b4c0ee309fb" TYPE="vdo"
/dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
UUID="2c541b70-32c5-496e-863f-ea68b50e7671" TYPE="vdo"
/dev/mapper/vdo_gluster_ssd: UUID="e59a68d5-2b73-487a-ac5e-409e11402ab5"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme1: UUID="d5f53f17-bca1-4cb9-86d5-34a468c062e7"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme2: UUID="40a41b5f-be87-4994-b6ea-793cdfc076a4"
TYPE="xfs"
#2
/dev/nvme0n1: PTTYPE="dos"
/dev/nvme1n1: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020p1:
UUID="GiBSqT-JJ3r-Tn3X-lzCr-zW3D-F3IE-OpE4Ga" TYPE="LVM2_member"
/dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-00000001:
PTTYPE="dos"
/dev/sda: PTTYPE="gpt"
/dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-00000001p1:
UUID="JBhj79-Uk0E-DdLE-Ibof-VwBq-T5nZ-F8d57O" TYPE="LVM2_member"
/dev/sdb: PTTYPE="dos"
/dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B: PTTYPE="dos"
/dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B1:
UUID="6yp5YM-D1be-M27p-AEF5-w1pv-uXNF-2vkiJZ" TYPE="LVM2_member"
/dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
UUID="9643695c-0ace-4cba-a42c-3f337a7d5133" TYPE="vdo"
/dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
UUID="79f5bacc-cbe7-4b67-be05-414f68818f41" TYPE="vdo"
/dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
UUID="2438a550-5fb4-48f4-a5ef-5cff5e7d5ba8" TYPE="vdo"
/dev/mapper/vdo_gluster_ssd: UUID="5bb67f61-9d14-4d0b-8aa4-ae3905276797"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme1: UUID="732f939c-f133-4e48-8dc8-c9d21dbc0853"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme2: UUID="f55082ca-1269-4477-9bf8-7190f1add9ef"
TYPE="xfs"
#3
/dev/nvme1n1: UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32" TYPE="vdo"
/dev/nvme0n1: PTTYPE="dos"
/dev/mapper/nvme.c0a9-313931304531454644323630-4354353030503153534438-00000001:
UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32" TYPE="vdo"
/dev/mapper/eui.6479a71892882020: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020p1:
UUID="FwBRJJ-ofHI-1kHq-uEf1-H3Fn-SQcw-qWYvmL" TYPE="LVM2_member"
/dev/sda: PTTYPE="gpt"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A: PTTYPE="gpt"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A1:
UUID="weCmOq-VZ1a-Itf5-SOIS-AYLp-Ud5N-S1H2bR" TYPE="LVM2_member"
PARTUUID="920ef5fd-e525-4cf0-99d5-3951d3013c19"
/dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
UUID="fbaffbde-74f0-4e4a-9564-64ca84398cde" TYPE="vdo"
/dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
UUID="ae0bd2ad-7da9-485b-824a-72038571c5ba" TYPE="vdo"
/dev/mapper/vdo_gluster_ssd: UUID="f0f56784-bc71-46c7-8bfe-6b71327c87c9"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme1: UUID="0ddc1180-f228-4209-82f1-1607a46aed1f"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme2: UUID="bcb7144a-6ce0-4b3f-9537-f465c46d4843"
TYPE="xfs"
I don't have any errors on mount until I reboot, and once I reboot it takes ~6hrs for
everything to work 100% since I have to delete the mount commands out of stab for the 3
gluster volumes and reboot. I'da rather wait until the next update to do that.
I don't have a variable file or playbook since I made the storage manually, I stopped
using the playbook since at that point I couldn't enable RDMA or over-provision the
disks correctly unless I made them manually. But as I said, this is something in 4.3.3 as
if I go back to 4.3.2 I can reboot no problem.
1:58 p.m.
New subject: oVirt node loses gluster volume UUID after reboot, goes to emergency mode every time I reboot.
Do you use VDO ?If yes, consider setting up systemd ".mount" units, as this is
the only way to setup dependencies.
Best Regards,Strahil Nikolov
В вторник, 21 май 2019 г., 22:44:06 ч. Гринуич+3, michael(a)wanderingmad.com
<michael(a)wanderingmad.com> написа:
I'm sorry, i'm still working on my linux knowledge, here is the output of my
blkid on one of the servers:
/dev/nvme0n1: PTTYPE="dos"
/dev/nvme1n1: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020: PTTYPE="dos"
/dev/mapper/eui.0025385881b40f60: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020p1:
UUID="pfJiP3-HCgP-gCyQ-UIzT-akGk-vRpV-aySGZ2" TYPE="LVM2_member"
/dev/mapper/eui.0025385881b40f60p1:
UUID="Q0fyzN-9q0s-WDLe-r0IA-MFY0-tose-yzZeu2" TYPE="LVM2_member"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H: PTTYPE="dos"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H1:
UUID="lQrtPt-nx0u-P6Or-f2YW-sN2o-jK9I-gp7P2m" TYPE="LVM2_member"
/dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
UUID="890feffe-c11b-4c01-b839-a5906ab39ecb" TYPE="vdo"
/dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
UUID="7049fd2a-788d-44cb-9dc5-7b4c0ee309fb" TYPE="vdo"
/dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
UUID="2c541b70-32c5-496e-863f-ea68b50e7671" TYPE="vdo"
/dev/mapper/vdo_gluster_ssd: UUID="e59a68d5-2b73-487a-ac5e-409e11402ab5"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme1: UUID="d5f53f17-bca1-4cb9-86d5-34a468c062e7"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme2: UUID="40a41b5f-be87-4994-b6ea-793cdfc076a4"
TYPE="xfs"
#2
/dev/nvme0n1: PTTYPE="dos"
/dev/nvme1n1: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020p1:
UUID="GiBSqT-JJ3r-Tn3X-lzCr-zW3D-F3IE-OpE4Ga" TYPE="LVM2_member"
/dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-00000001:
PTTYPE="dos"
/dev/sda: PTTYPE="gpt"
/dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-00000001p1:
UUID="JBhj79-Uk0E-DdLE-Ibof-VwBq-T5nZ-F8d57O" TYPE="LVM2_member"
/dev/sdb: PTTYPE="dos"
/dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B: PTTYPE="dos"
/dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B1:
UUID="6yp5YM-D1be-M27p-AEF5-w1pv-uXNF-2vkiJZ" TYPE="LVM2_member"
/dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
UUID="9643695c-0ace-4cba-a42c-3f337a7d5133" TYPE="vdo"
/dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
UUID="79f5bacc-cbe7-4b67-be05-414f68818f41" TYPE="vdo"
/dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
UUID="2438a550-5fb4-48f4-a5ef-5cff5e7d5ba8" TYPE="vdo"
/dev/mapper/vdo_gluster_ssd: UUID="5bb67f61-9d14-4d0b-8aa4-ae3905276797"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme1: UUID="732f939c-f133-4e48-8dc8-c9d21dbc0853"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme2: UUID="f55082ca-1269-4477-9bf8-7190f1add9ef"
TYPE="xfs"
#3
/dev/nvme1n1: UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32" TYPE="vdo"
/dev/nvme0n1: PTTYPE="dos"
/dev/mapper/nvme.c0a9-313931304531454644323630-4354353030503153534438-00000001:
UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32" TYPE="vdo"
/dev/mapper/eui.6479a71892882020: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020p1:
UUID="FwBRJJ-ofHI-1kHq-uEf1-H3Fn-SQcw-qWYvmL" TYPE="LVM2_member"
/dev/sda: PTTYPE="gpt"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A: PTTYPE="gpt"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A1:
UUID="weCmOq-VZ1a-Itf5-SOIS-AYLp-Ud5N-S1H2bR" TYPE="LVM2_member"
PARTUUID="920ef5fd-e525-4cf0-99d5-3951d3013c19"
/dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
UUID="fbaffbde-74f0-4e4a-9564-64ca84398cde" TYPE="vdo"
/dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
UUID="ae0bd2ad-7da9-485b-824a-72038571c5ba" TYPE="vdo"
/dev/mapper/vdo_gluster_ssd: UUID="f0f56784-bc71-46c7-8bfe-6b71327c87c9"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme1: UUID="0ddc1180-f228-4209-82f1-1607a46aed1f"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme2: UUID="bcb7144a-6ce0-4b3f-9537-f465c46d4843"
TYPE="xfs"
I don't have any errors on mount until I reboot, and once I reboot it takes ~6hrs for
everything to work 100% since I have to delete the mount commands out of stab for the 3
gluster volumes and reboot. I'da rather wait until the next update to do that.
I don't have a variable file or playbook since I made the storage manually, I stopped
using the playbook since at that point I couldn't enable RDMA or over-provision the
disks correctly unless I made them manually. But as I said, this is something in 4.3.3 as
if I go back to 4.3.2 I can reboot no problem.
_______________________________________________
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/
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/EDGJVIYPMHN...
10:56 p.m.
New subject: oVirt node loses gluster volume UUID after reboot, goes to emergency mode every time I reboot.
+Sachidananda URS <surs(a)redhat.com>
On Wed, May 22, 2019 at 1:14 AM <michael(a)wanderingmad.com> wrote:
I'm sorry, i'm still working on my linux knowledge, here is
the output of
my blkid on one of the servers:
/dev/nvme0n1: PTTYPE="dos"
/dev/nvme1n1: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020: PTTYPE="dos"
/dev/mapper/eui.0025385881b40f60: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020p1:
UUID="pfJiP3-HCgP-gCyQ-UIzT-akGk-vRpV-aySGZ2" TYPE="LVM2_member"
/dev/mapper/eui.0025385881b40f60p1:
UUID="Q0fyzN-9q0s-WDLe-r0IA-MFY0-tose-yzZeu2" TYPE="LVM2_member"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H: PTTYPE="dos"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H1:
UUID="lQrtPt-nx0u-P6Or-f2YW-sN2o-jK9I-gp7P2m" TYPE="LVM2_member"
/dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
UUID="890feffe-c11b-4c01-b839-a5906ab39ecb" TYPE="vdo"
/dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
UUID="7049fd2a-788d-44cb-9dc5-7b4c0ee309fb" TYPE="vdo"
/dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
UUID="2c541b70-32c5-496e-863f-ea68b50e7671" TYPE="vdo"
/dev/mapper/vdo_gluster_ssd: UUID="e59a68d5-2b73-487a-ac5e-409e11402ab5"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme1: UUID="d5f53f17-bca1-4cb9-86d5-34a468c062e7"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme2: UUID="40a41b5f-be87-4994-b6ea-793cdfc076a4"
TYPE="xfs"
#2
/dev/nvme0n1: PTTYPE="dos"
/dev/nvme1n1: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020p1:
UUID="GiBSqT-JJ3r-Tn3X-lzCr-zW3D-F3IE-OpE4Ga" TYPE="LVM2_member"
/dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-00000001:
PTTYPE="dos"
/dev/sda: PTTYPE="gpt"
/dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-00000001p1:
UUID="JBhj79-Uk0E-DdLE-Ibof-VwBq-T5nZ-F8d57O" TYPE="LVM2_member"
/dev/sdb: PTTYPE="dos"
/dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B: PTTYPE="dos"
/dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B1:
UUID="6yp5YM-D1be-M27p-AEF5-w1pv-uXNF-2vkiJZ" TYPE="LVM2_member"
/dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
UUID="9643695c-0ace-4cba-a42c-3f337a7d5133" TYPE="vdo"
/dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
UUID="79f5bacc-cbe7-4b67-be05-414f68818f41" TYPE="vdo"
/dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
UUID="2438a550-5fb4-48f4-a5ef-5cff5e7d5ba8" TYPE="vdo"
/dev/mapper/vdo_gluster_ssd: UUID="5bb67f61-9d14-4d0b-8aa4-ae3905276797"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme1: UUID="732f939c-f133-4e48-8dc8-c9d21dbc0853"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme2: UUID="f55082ca-1269-4477-9bf8-7190f1add9ef"
TYPE="xfs"
#3
/dev/nvme1n1: UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32" TYPE="vdo"
/dev/nvme0n1: PTTYPE="dos"
/dev/mapper/nvme.c0a9-313931304531454644323630-4354353030503153534438-00000001:
UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32" TYPE="vdo"
/dev/mapper/eui.6479a71892882020: PTTYPE="dos"
/dev/mapper/eui.6479a71892882020p1:
UUID="FwBRJJ-ofHI-1kHq-uEf1-H3Fn-SQcw-qWYvmL" TYPE="LVM2_member"
/dev/sda: PTTYPE="gpt"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A: PTTYPE="gpt"
/dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A1:
UUID="weCmOq-VZ1a-Itf5-SOIS-AYLp-Ud5N-S1H2bR" TYPE="LVM2_member"
PARTUUID="920ef5fd-e525-4cf0-99d5-3951d3013c19"
/dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
UUID="fbaffbde-74f0-4e4a-9564-64ca84398cde" TYPE="vdo"
/dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
UUID="ae0bd2ad-7da9-485b-824a-72038571c5ba" TYPE="vdo"
/dev/mapper/vdo_gluster_ssd: UUID="f0f56784-bc71-46c7-8bfe-6b71327c87c9"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme1: UUID="0ddc1180-f228-4209-82f1-1607a46aed1f"
TYPE="xfs"
/dev/mapper/vdo_gluster_nvme2: UUID="bcb7144a-6ce0-4b3f-9537-f465c46d4843"
TYPE="xfs"
I don't have any errors on mount until I reboot, and once I reboot it
takes ~6hrs for everything to work 100% since I have to delete the mount
commands out of stab for the 3 gluster volumes and reboot. I'da rather
wait until the next update to do that.
I don't have a variable file or playbook since I made the storage
manually, I stopped using the playbook since at that point I couldn't
enable RDMA or over-provision the disks correctly unless I made them
manually. But as I said, this is something in 4.3.3 as if I go back to
4.3.2 I can reboot no problem.
_______________________________________________
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/
oVirt Code of Conduct:
https://www.ovirt.org/community/about/community-guidelines/
List Archives:
https://lists.ovirt.org/archives/list/users@ovirt.org/message/EDGJVIYPMHN...
11:13 p.m.
New subject: oVirt node loses gluster volume UUID after reboot, goes to emergency mode every time I reboot.
On Wed, May 22, 2019 at 11:26 AM Sahina Bose <sabose(a)redhat.com> wrote:
+Sachidananda URS <surs(a)redhat.com>
On Wed, May 22, 2019 at 1:14 AM <michael(a)wanderingmad.com> wrote:
> I'm sorry, i'm still working on my linux knowledge, here is the output of
> my blkid on one of the servers:
>
> /dev/nvme0n1: PTTYPE="dos"
> /dev/nvme1n1: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020: PTTYPE="dos"
> /dev/mapper/eui.0025385881b40f60: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020p1:
> UUID="pfJiP3-HCgP-gCyQ-UIzT-akGk-vRpV-aySGZ2" TYPE="LVM2_member"
> /dev/mapper/eui.0025385881b40f60p1:
> UUID="Q0fyzN-9q0s-WDLe-r0IA-MFY0-tose-yzZeu2" TYPE="LVM2_member"
>
> /dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H: PTTYPE="dos"
> /dev/mapper/Samsung_SSD_850_EVO_1TB_S21CNXAG615134H1:
> UUID="lQrtPt-nx0u-P6Or-f2YW-sN2o-jK9I-gp7P2m" TYPE="LVM2_member"
> /dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
> UUID="890feffe-c11b-4c01-b839-a5906ab39ecb" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
> UUID="7049fd2a-788d-44cb-9dc5-7b4c0ee309fb" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
> UUID="2c541b70-32c5-496e-863f-ea68b50e7671" TYPE="vdo"
> /dev/mapper/vdo_gluster_ssd: UUID="e59a68d5-2b73-487a-ac5e-409e11402ab5"
> TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme1:
> UUID="d5f53f17-bca1-4cb9-86d5-34a468c062e7" TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme2:
> UUID="40a41b5f-be87-4994-b6ea-793cdfc076a4" TYPE="xfs"
>
> #2
> /dev/nvme0n1: PTTYPE="dos"
> /dev/nvme1n1: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020p1:
> UUID="GiBSqT-JJ3r-Tn3X-lzCr-zW3D-F3IE-OpE4Ga" TYPE="LVM2_member"
>
/dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-00000001:
> PTTYPE="dos"
> /dev/sda: PTTYPE="gpt"
>
/dev/mapper/nvme.126f-324831323230303337383138-4144415441205358383030304e50-00000001p1:
> UUID="JBhj79-Uk0E-DdLE-Ibof-VwBq-T5nZ-F8d57O" TYPE="LVM2_member"
> /dev/sdb: PTTYPE="dos"
> /dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B: PTTYPE="dos"
> /dev/mapper/Samsung_SSD_860_EVO_1TB_S3Z8NB0K843638B1:
> UUID="6yp5YM-D1be-M27p-AEF5-w1pv-uXNF-2vkiJZ" TYPE="LVM2_member"
> /dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
> UUID="9643695c-0ace-4cba-a42c-3f337a7d5133" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
> UUID="79f5bacc-cbe7-4b67-be05-414f68818f41" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme1-lv_gluster_nvme1:
> UUID="2438a550-5fb4-48f4-a5ef-5cff5e7d5ba8" TYPE="vdo"
> /dev/mapper/vdo_gluster_ssd: UUID="5bb67f61-9d14-4d0b-8aa4-ae3905276797"
> TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme1:
> UUID="732f939c-f133-4e48-8dc8-c9d21dbc0853" TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme2:
> UUID="f55082ca-1269-4477-9bf8-7190f1add9ef" TYPE="xfs"
>
> #3
> /dev/nvme1n1: UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32"
TYPE="vdo"
> /dev/nvme0n1: PTTYPE="dos"
> /dev/mapper/nvme.c0a9-313931304531454644323630-4354353030503153534438-00000001:
> UUID="8f1dc44e-f35f-438a-9abc-54757fd7ef32" TYPE="vdo"
> /dev/mapper/eui.6479a71892882020: PTTYPE="dos"
> /dev/mapper/eui.6479a71892882020p1:
> UUID="FwBRJJ-ofHI-1kHq-uEf1-H3Fn-SQcw-qWYvmL" TYPE="LVM2_member"
> /dev/sda: PTTYPE="gpt"
> /dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A: PTTYPE="gpt"
> /dev/mapper/Samsung_SSD_850_EVO_1TB_S2RENX0J302798A1:
> UUID="weCmOq-VZ1a-Itf5-SOIS-AYLp-Ud5N-S1H2bR" TYPE="LVM2_member"
> PARTUUID="920ef5fd-e525-4cf0-99d5-3951d3013c19"
> /dev/mapper/vg_gluster_ssd-lv_gluster_ssd:
> UUID="fbaffbde-74f0-4e4a-9564-64ca84398cde" TYPE="vdo"
> /dev/mapper/vg_gluster_nvme2-lv_gluster_nvme2:
> UUID="ae0bd2ad-7da9-485b-824a-72038571c5ba" TYPE="vdo"
> /dev/mapper/vdo_gluster_ssd: UUID="f0f56784-bc71-46c7-8bfe-6b71327c87c9"
> TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme1:
> UUID="0ddc1180-f228-4209-82f1-1607a46aed1f" TYPE="xfs"
> /dev/mapper/vdo_gluster_nvme2:
> UUID="bcb7144a-6ce0-4b3f-9537-f465c46d4843" TYPE="xfs"
>
> I don't have any errors on mount until I reboot, and once I reboot it
> takes ~6hrs for everything to work 100% since I have to delete the mount
> commands out of stab for the 3 gluster volumes and reboot. I'da rather
> wait until the next update to do that.
>
> I don't have a variable file or playbook since I made the storage
> manually, I stopped using the playbook since at that point I couldn't
> enable RDMA or over-provision the disks correctly unless I made them
> manually. But as I said, this is something in 4.3.3 as if I go back to
> 4.3.2 I can reboot no problem.
>
Ah okay. since you are using VDO, the fstab entry should look something
like this:
UUID=4f1f2e90-5a22-4995-9dd4-7ab9a7ddb438 /gluster_bricks/engine xfs
inode64,noatime,nodiratime,_netdev,x-systemd.device-timeout=0,x-systemd.requires=vdo.service
0 0
That is what gluster-ansible will be adding to the fstab file. This entry
will be added if you had used the
variable gluster_infra_vdo ... How did you create your filesystem, is it
manually or using the deploy script?
Can you please share your variable file that you used to deploy?
-sac
9:09 p.m.
New subject: oVirt node loses gluster volume UUID after reboot, goes to emergency mode every time I reboot.
I made them manually. First created the LVM drives, then the VDO devices, then gluster
volumes
11:48 p.m.
New subject: oVirt node loses gluster volume UUID after reboot, goes to emergency mode every time I reboot.
On Mon, May 27, 2019 at 9:41 AM <michael(a)wanderingmad.com> wrote:
I made them manually. First created the LVM drives, then the VDO
devices,
then gluster volumes
In that case you must add these mount options (
inode64,noatime,nodiratime,_netdev,x-systemd.device-timeout=0,x-systemd.requires=vdo.service)
manually into fstab.
gluster-ansible would have added it if you had done end-to-end deployment
or declared the necessary variables.
-sac
1797
days inactive
1816
days old
8 comments
4 participants
participants (4)
-
michael＠wanderingmad.com -
Sachidananda URS -
Sahina Bose -
Strahil Nikolov