- Users - oVirt List Archives

Unable to start vdsm, upgrade 4.0 to 4.1
by Todd Barton 13 Apr '19

13 Apr '19

Looking for some help/suggestions to correct an issue I'm having. I have a 3 host HA setup running a hosted-engine and gluster storage. The hosts are identical hardware configurations and have been running for several years very solidly. I was performing an upgrade to 4.1. 1st host when fine. The second upgrade didn't go well...On server reboot, it went into kernel panic and I had to load previous kernel to diagnose. I couldn't get it out of panic and I had to revert the system to the previous kernel which was a big PITA. I updated it to current and verified installation of ovirt/vdsm. Everything seemed to be ok, but vdsm won't start. Gluster is working fine. It appears I have a authentication issue with libvirt. I'm getting the message "libvirt: XML-RPC error : authentication failed: authentication failed" which seems to be the core issue. I've looked at all the past issues/resolutions to this issue and tried them, but I can't get it to work. For example, I do a vdsm-tool configure --force and I get this... Checking configuration status... abrt is already configured for vdsm lvm is configured for vdsm libvirt is already configured for vdsm SUCCESS: ssl configured to true. No conflicts Current revision of multipath.conf detected, preserving Running configure... Reconfiguration of abrt is done. Traceback (most recent call last): File "/usr/bin/vdsm-tool", line 219, in main return tool_command[cmd]["command"](*args) File "/usr/lib/python2.7/site-packages/vdsm/tool/__init__.py", line 38, in wrapper func(*args, **kwargs) File "/usr/lib/python2.7/site-packages/vdsm/tool/configurator.py", line 141, in configure _configure(c) File "/usr/lib/python2.7/site-packages/vdsm/tool/configurator.py", line 88, in _configure getattr(module, 'configure', lambda: None)() File "/usr/lib/python2.7/site-packages/vdsm/tool/configurators/passwd.py", line 68, in configure configure_passwd() File "/usr/lib/python2.7/site-packages/vdsm/tool/configurators/passwd.py", line 98, in configure_passwd raise RuntimeError("Set password failed: %s" % (err,)) RuntimeError: Set password failed: ['saslpasswd2: invalid parameter supplied'] ...and help would be greatly appreciated. I'm not a linux/ovirt expert by any means, but I desperately need to get this setup back to being stable. This happened many months ago and I gave up fixing, but I really need to get this back online again. Thank you Todd Barton

2 1

Re: Unable to start vdsm, upgrade 4.0 to 4.1
by Strahil 13 Apr '19

13 Apr '19

The fastest (windows style) approach is to completely wipe the host and do a reinstall -> install in vdsm and so on. You should consider oVirt Node. Another one that comes to my mind is to do: yum history yum history rollback <id> reboot repeat the upgrade. For now, I'm planing to do gluster snapshots (all machines on volume -> stopped) before major upgrades, as this is the fastest recovery approach. Actually oVirt Node uses thin lvm snapshots to guarantee fast rollback. Best Regards, Strahil NikolovOn Apr 13, 2019 06:44, Todd Barton <tcbarton(a)ipvoicedatasystems.com> wrote: > > Looking for some help/suggestions to correct an issue I'm having. I have a 3 host HA setup running a hosted-engine and gluster storage. The hosts are identical hardware configurations and have been running for several years very solidly. I was performing an upgrade to 4.1. 1st host when fine. The second upgrade didn't go well...On server reboot, it went into kernel panic and I had to load previous kernel to diagnose. > > I couldn't get it out of panic and I had to revert the system to the previous kernel which was a big PITA. I updated it to current and verified installation of ovirt/vdsm. Everything seemed to be ok, but vdsm won't start. Gluster is working fine. It appears I have a authentication issue with libvirt. I'm getting the message "libvirt: XML-RPC error : authentication failed: authentication failed" which seems to be the core issue. > > I've looked at all the past issues/resolutions to this issue and tried them, but I can't get it to work. For example, I do a vdsm-tool configure --force and I get this... > > Checking configuration status... > > abrt is already configured for vdsm > lvm is configured for vdsm > libvirt is already configured for vdsm > SUCCESS: ssl configured to true. No conflicts > Current revision of multipath.conf detected, preserving > > Running configure... > Reconfiguration of abrt is done. > Traceback (most recent call last): > File "/usr/bin/vdsm-tool", line 219, in main > return tool_command[cmd]["command"](*args) > File "/usr/lib/python2.7/site-packages/vdsm/tool/__init__.py", line 38, in wrapper > func(*args, **kwargs) > File "/usr/lib/python2.7/site-packages/vdsm/tool/configurator.py", line 141, in configure > _configure(c) > File "/usr/lib/python2.7/site-packages/vdsm/tool/configurator.py", line 88, in _configure > getattr(module, 'configure', lambda: None)() > File "/usr/lib/python2.7/site-packages/vdsm/tool/configurators/passwd.py", line 68, in configure > configure_passwd() > File "/usr/lib/python2.7/site-packages/vdsm/tool/configurators/passwd.py", line 98, in configure_passwd > raise RuntimeError("Set password failed: %s" % (err,)) > RuntimeError: Set password failed: ['saslpasswd2: invalid parameter supplied'] > > ...and help would be greatly appreciated. I'm not a linux/ovirt expert by any means, but I desperately need to get this setup back to being stable. This happened many months ago and I gave up fixing, but I really need to get this back online again. > > Thank you > > Todd Barton > > > > >

2 1

Tuning Gluster Writes
by Alex McWhirter 12 Apr '19

12 Apr '19

I have 8 machines acting as gluster servers. They each have 12 drives raid 50'd together (3 sets of 4 drives raid 5'd then 0'd together as one). They connect to the compute hosts and to each other over lacp'd 10GB connections split across two cisco nexus switched with VPC. Gluster has the following set. performance.write-behind-window-size: 4MB performance.flush-behind: on performance.stat-prefetch: on server.event-threads: 4 client.event-threads: 8 performance.io-thread-count: 32 network.ping-timeout: 30 cluster.granular-entry-heal: enable performance.strict-o-direct: on storage.owner-gid: 36 storage.owner-uid: 36 features.shard: on cluster.shd-wait-qlength: 10000 cluster.shd-max-threads: 8 cluster.locking-scheme: granular cluster.data-self-heal-algorithm: full cluster.server-quorum-type: server cluster.quorum-type: auto cluster.eager-lock: enable network.remote-dio: off performance.low-prio-threads: 32 performance.io-cache: off performance.read-ahead: off performance.quick-read: off auth.allow: * user.cifs: off transport.address-family: inet nfs.disable: off performance.client-io-threads: on I have the following sysctl values on gluster client and servers, using libgfapi, MTU 9K net.core.rmem_max = 134217728 net.core.wmem_max = 134217728 net.ipv4.tcp_rmem = 4096 87380 134217728 net.ipv4.tcp_wmem = 4096 65536 134217728 net.core.netdev_max_backlog = 300000 net.ipv4.tcp_moderate_rcvbuf =1 net.ipv4.tcp_no_metrics_save = 1 net.ipv4.tcp_congestion_control=htcp reads with this setup are perfect, benchmarked in VM to be about 770MB/s sequential with disk access times of < 1ms. Writes on the other hand are all over the place. They peak around 320MB/s sequential write, which is what i expect but it seems as if there is some blocking going on. During the write test i will hit 320MB/s briefly, then 0MB/s as disk access time shoot to over 3000ms, then back to 320MB/s. It averages out to about 110MB/s afterwards. Gluster version is 3.12.15 ovirt is 4.2.7.5 Any ideas on what i could tune to eliminate or minimize that blocking?

1 0

Migrate self-hosted engine between cluster
by raul.caballero.girol＠gmail.com 12 Apr '19

12 Apr '19

Hello everibody, Iḿ a noob with ovirt and I have a problem. I have deployed a new enviroment with a self-hosted engine. Now, when I am learning about ovirt, I think that my engine should be in another cluster. How I can move my manage from one cluster to other?. Cheers

3 3

Re: Cannot allocate and run VM from VM-Pool. There are no available VMs in the VM-Pool
by nicolas＠devels.es 12 Apr '19

12 Apr '19

Are the VMs from the pool 'up'? If so, no assignation can be done unless they are powered off. El 2019-04-12 14:31, Florian Rädler escribió: > I am getting the following Error after a Pool was generated and > migrated to another host. > > START_POOL fehlgeschlagen [Cannot allocate and run VM from VM-Pool. > There are no available VMs in the VM-Pool.] > > No user is connected to any of the running VMs. What can I do to solve > this problem? > > ------------------------- > > Pflichtangaben anzeigen [1] > > Nähere Informationen zur Datenverarbeitung im DB-Konzern finden Sie > hier: http://www.deutschebahn.com/de/konzern/datenschutz [2] > > Links: > ------ > [1] http://www.deutschebahn.com/pflichtangaben/20190408 > [2] http://www.deutschebahn.com/de/konzern/datenschutz > > _______________________________________________ > 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/UL2KJKETQYFZR…

1 0

Cannot allocate and run VM from VM-Pool. There are no available VMs in the VM-Pool
by Florian Rädler 12 Apr '19

12 Apr '19

I am getting the following Error after a Pool was generated and migrated to another host. START_POOL fehlgeschlagen [Cannot allocate and run VM from VM-Pool. There are no available VMs in the VM-Pool.] No user is connected to any of the running VMs. What can I do to solve this problem? ________________________________ Pflichtangaben anzeigen<http://www.deutschebahn.com/pflichtangaben/20190408> Nähere Informationen zur Datenverarbeitung im DB-Konzern finden Sie hier: http://www.deutschebahn.com/de/konzern/datenschutz

1 0

[ANN] oVirt 4.3.3 Fourth Release Candidate is now available
by Sandro Bonazzola 12 Apr '19

12 Apr '19

The oVirt Project is pleased to announce the availability of the oVirt 4.3.3 Fourth Release Candidate, as of April 12th, 2019. This update is a release candidate of the third in a series of stabilization updates to the 4.3 series. This is pre-release software. This pre-release should not to be used in production. This release is available now on x86_64 architecture for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later This release supports Hypervisor Hosts on x86_64 and ppc64le architectures for: * Red Hat Enterprise Linux 7.6 or later * CentOS Linux (or similar) 7.6 or later * oVirt Node 4.3 (available for x86_64 only) Experimental tech preview for x86_64 and s390x architectures for Fedora 28 is also included. See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: - oVirt Appliance will be available soon - oVirt Node will be available soon[2] Additional Resources: * Read more about the oVirt 4.3.3 release highlights: http://www.ovirt.org/release/4.3.3/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/4.3.3/ [2] http://resources.ovirt.org/pub/ovirt-4.3-pre/iso/ -- SANDRO BONAZZOLA MANAGER, SOFTWARE ENGINEERING, EMEA R&D RHV Red Hat EMEA <https://www.redhat.com/> sbonazzo(a)redhat.com <https://red.ht/sig>

1 0

Re: [Gluster-users] Gluster snapshot fails
by Strahil Nikolov 12 Apr '19

12 Apr '19

Hello All, I have tried to enable debug and see the reason for the issue. Here is the relevant glusterd.log: [2019-04-12 07:56:54.526508] E [MSGID: 106077] [glusterd-snapshot.c:1882:glusterd_is_thinp_brick] 0-management: Failed to get pool name for device systemd-1 [2019-04-12 07:56:54.527509] E [MSGID: 106121] [glusterd-snapshot.c:2523:glusterd_snapshot_create_prevalidate] 0-management: Failed to pre validate [2019-04-12 07:56:54.527525] E [MSGID: 106024] [glusterd-snapshot.c:2547:glusterd_snapshot_create_prevalidate] 0-management: Snapshot is supported only for thin provisioned LV. Ensure that all bricks of isos are thinly provisioned LV. [2019-04-12 07:56:54.527539] W [MSGID: 106029] [glusterd-snapshot.c:8613:glusterd_snapshot_prevalidate] 0-management: Snapshot create pre-validation failed [2019-04-12 07:56:54.527552] W [MSGID: 106121] [glusterd-mgmt.c:147:gd_mgmt_v3_pre_validate_fn] 0-management: Snapshot Prevalidate Failed [2019-04-12 07:56:54.527568] E [MSGID: 106121] [glusterd-mgmt.c:1015:glusterd_mgmt_v3_pre_validate] 0-management: Pre Validation failed for operation Snapshot on local node [2019-04-12 07:56:54.527583] E [MSGID: 106121] [glusterd-mgmt.c:2377:glusterd_mgmt_v3_initiate_snap_phases] 0-management: Pre Validation Failed here is the output of lvscan & lvs: [root@ovirt1 ~]# lvscan ACTIVE '/dev/gluster_vg_md0/my_vdo_thinpool' [9.86 TiB] inherit ACTIVE '/dev/gluster_vg_md0/gluster_lv_data' [500.00 GiB] inherit ACTIVE '/dev/gluster_vg_md0/gluster_lv_isos' [50.00 GiB] inherit ACTIVE '/dev/gluster_vg_ssd/my_ssd_thinpool' [168.59 GiB] inherit ACTIVE '/dev/gluster_vg_ssd/gluster_lv_engine' [40.00 GiB] inherit ACTIVE '/dev/centos_ovirt1/swap' [6.70 GiB] inherit ACTIVE '/dev/centos_ovirt1/home' [1.00 GiB] inherit ACTIVE '/dev/centos_ovirt1/root' [60.00 GiB] inherit [root@ovirt1 ~]# lvs --noheadings -o pool_lv my_vdo_thinpool my_vdo_thinpool my_ssd_thinpool [root@ovirt1 ~]# ssh ovirt2 "lvscan;lvs --noheadings -o pool_lv" ACTIVE '/dev/gluster_vg_md0/my_vdo_thinpool' [<9.77 TiB] inherit ACTIVE '/dev/gluster_vg_md0/gluster_lv_data' [500.00 GiB] inherit ACTIVE '/dev/gluster_vg_md0/gluster_lv_isos' [50.00 GiB] inherit ACTIVE '/dev/gluster_vg_ssd/my_ssd_thinpool' [<161.40 GiB] inherit ACTIVE '/dev/gluster_vg_ssd/gluster_lv_engine' [40.00 GiB] inherit ACTIVE '/dev/centos_ovirt2/root' [15.00 GiB] inherit ACTIVE '/dev/centos_ovirt2/home' [1.00 GiB] inherit ACTIVE '/dev/centos_ovirt2/swap' [16.00 GiB] inherit my_vdo_thinpool my_vdo_thinpool my_ssd_thinpool [root@ovirt1 ~]# ssh ovirt3 "lvscan;lvs --noheadings -o pool_lv" ACTIVE '/dev/gluster_vg_sda3/gluster_thinpool_sda3' [41.00 GiB] inherit ACTIVE '/dev/gluster_vg_sda3/gluster_lv_data' [15.00 GiB] inherit ACTIVE '/dev/gluster_vg_sda3/gluster_lv_isos' [15.00 GiB] inherit ACTIVE '/dev/gluster_vg_sda3/gluster_lv_engine' [15.00 GiB] inherit ACTIVE '/dev/centos_ovirt3/root' [20.00 GiB] inherit ACTIVE '/dev/centos_ovirt3/home' [1.00 GiB] inherit ACTIVE '/dev/centos_ovirt3/swap' [8.00 GiB] inherit gluster_thinpool_sda3 gluster_thinpool_sda3 gluster_thinpool_sda3 I am mounting my bricks via systemd , as I have issues with bricks being started before VDO. [root@ovirt1 ~]# findmnt /gluster_bricks/isos TARGET SOURCE FSTYPE OPTIONS /gluster_bricks/isos systemd-1 autofs rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21843 /gluster_bricks/isos /dev/mapper/gluster_vg_md0-gluster_lv_isos xfs rw,noatime,nodiratime,seclabel,attr2,inode64,noquota [root@ovirt1 ~]# ssh ovirt2 "findmnt /gluster_bricks/isos " TARGET SOURCE FSTYPE OPTIONS /gluster_bricks/isos systemd-1 autofs rw,relatime,fd=26,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=14279 /gluster_bricks/isos /dev/mapper/gluster_vg_md0-gluster_lv_isos xfs rw,noatime,nodiratime,seclabel,attr2,inode64,noquota [root@ovirt1 ~]# ssh ovirt3 "findmnt /gluster_bricks/isos " TARGET SOURCE FSTYPE OPTIONS /gluster_bricks/isos systemd-1 autofs rw,relatime,fd=35,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=17770 /gluster_bricks/isos /dev/mapper/gluster_vg_sda3-gluster_lv_isos xfs rw,noatime,nodiratime,seclabel,attr2,inode64,logbsize=256k,sunit=512,swidth=1024,noquota [root@ovirt1 ~]# grep "gluster_bricks" /proc/mounts systemd-1 /gluster_bricks/data autofs rw,relatime,fd=22,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21513 0 0 systemd-1 /gluster_bricks/engine autofs rw,relatime,fd=25,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21735 0 0 systemd-1 /gluster_bricks/isos autofs rw,relatime,fd=31,pgrp=1,timeout=0,minproto=5,maxproto=5,direct,pipe_ino=21843 0 0 /dev/mapper/gluster_vg_ssd-gluster_lv_engine /gluster_bricks/engine xfs rw,seclabel,noatime,nodiratime,attr2,inode64,sunit=256,swidth=256,noquota 0 0 /dev/mapper/gluster_vg_md0-gluster_lv_isos /gluster_bricks/isos xfs rw,seclabel,noatime,nodiratime,attr2,inode64,noquota 0 0 /dev/mapper/gluster_vg_md0-gluster_lv_data /gluster_bricks/data xfs rw,seclabel,noatime,nodiratime,attr2,inode64,noquota 0 0 Obviously , gluster is catching "systemd-1" as a device and tries to check if it's a thin LV.Where should I open a bug for that ? P.S.: Adding oVirt User list. Best Regards,Strahil Nikolov В четвъртък, 11 април 2019 г., 4:00:31 ч. Гринуич-4, Strahil Nikolov <hunter86_bg(a)yahoo.com> написа: Hi Rafi, thanks for your update. I have tested again with another gluster volume.[root@ovirt1 glusterfs]# gluster volume info isos Volume Name: isos Type: Replicate Volume ID: 9b92b5bd-79f5-427b-bd8d-af28b038ed2a Status: Started Snapshot Count: 0 Number of Bricks: 1 x (2 + 1) = 3 Transport-type: tcp Bricks: Brick1: ovirt1:/gluster_bricks/isos/isos Brick2: ovirt2:/gluster_bricks/isos/isos Brick3: ovirt3.localdomain:/gluster_bricks/isos/isos (arbiter) Options Reconfigured: cluster.granular-entry-heal: enable performance.strict-o-direct: on network.ping-timeout: 30 storage.owner-gid: 36 storage.owner-uid: 36 user.cifs: off features.shard: on cluster.shd-wait-qlength: 10000 cluster.shd-max-threads: 8 cluster.locking-scheme: granular cluster.data-self-heal-algorithm: full cluster.server-quorum-type: server cluster.quorum-type: auto cluster.eager-lock: enable network.remote-dio: off performance.low-prio-threads: 32 performance.io-cache: off performance.read-ahead: off performance.quick-read: off transport.address-family: inet nfs.disable: on performance.client-io-threads: off cluster.enable-shared-storage: enable Command run: logrotate -f glusterfs ; logrotate -f glusterfs-georep; gluster snapshot create isos-snap-2019-04-11 isos description TEST Logs:[root@ovirt1 glusterfs]# cat cli.log [2019-04-11 07:51:02.367453] I [cli.c:769:main] 0-cli: Started running gluster with version 5.5 [2019-04-11 07:51:02.486863] I [MSGID: 101190] [event-epoll.c:621:event_dispatch_epoll_worker] 0-epoll: Started thread with index 1 [2019-04-11 07:51:02.556813] E [cli-rpc-ops.c:11293:gf_cli_snapshot] 0-cli: cli_to_glusterd for snapshot failed [2019-04-11 07:51:02.556880] I [input.c:31:cli_batch] 0-: Exiting with: -1 [root@ovirt1 glusterfs]# cat glusterd.log [2019-04-11 07:51:02.553357] E [MSGID: 106024] [glusterd-snapshot.c:2547:glusterd_snapshot_create_prevalidate] 0-management: Snapshot is supported only for thin provisioned LV. Ensure that all bricks of isos are thinly provisioned LV. [2019-04-11 07:51:02.553365] W [MSGID: 106029] [glusterd-snapshot.c:8613:glusterd_snapshot_prevalidate] 0-management: Snapshot create pre-validation failed [2019-04-11 07:51:02.553703] W [MSGID: 106121] [glusterd-mgmt.c:147:gd_mgmt_v3_pre_validate_fn] 0-management: Snapshot Prevalidate Failed [2019-04-11 07:51:02.553719] E [MSGID: 106121] [glusterd-mgmt.c:1015:glusterd_mgmt_v3_pre_validate] 0-management: Pre Validation failed for operation Snapshot on local node My LVs hosting the bricks are:[root@ovirt1 ~]# lvs gluster_vg_md0 LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert gluster_lv_data gluster_vg_md0 Vwi-aot--- 500.00g my_vdo_thinpool 35.97 gluster_lv_isos gluster_vg_md0 Vwi-aot--- 50.00g my_vdo_thinpool 52.11 my_vdo_thinpool gluster_vg_md0 twi-aot--- 9.86t 2.04 11.45 [root@ovirt1 ~]# ssh ovirt2 "lvs gluster_vg_md0" LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert gluster_lv_data gluster_vg_md0 Vwi-aot--- 500.00g my_vdo_thinpool 35.98 gluster_lv_isos gluster_vg_md0 Vwi-aot--- 50.00g my_vdo_thinpool 25.94 my_vdo_thinpool gluster_vg_md0 twi-aot--- <9.77t 1.93 11.39 [root@ovirt1 ~]# ssh ovirt3 "lvs gluster_vg_sda3" LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert gluster_lv_data gluster_vg_sda3 Vwi-aotz-- 15.00g gluster_thinpool_sda3 0.17 gluster_lv_engine gluster_vg_sda3 Vwi-aotz-- 15.00g gluster_thinpool_sda3 0.16 gluster_lv_isos gluster_vg_sda3 Vwi-aotz-- 15.00g gluster_thinpool_sda3 0.12 gluster_thinpool_sda3 gluster_vg_sda3 twi-aotz-- 41.00g 0.16 1.58 As you can see - all bricks are thin LV and space is not the issue. Can someone hint me how to enable debug , so gluster logs can show the reason for that pre-check failure ? Best Regards,Strahil Nikolov В сряда, 10 април 2019 г., 9:05:15 ч. Гринуич-4, Rafi Kavungal Chundattu Parambil <rkavunga(a)redhat.com> написа: Hi Strahil, The name of device is not at all a problem here. Can you please check the log of glusterd, and see if there is any useful information about the failure. Also please provide the output of `lvscan` and `lvs --noheadings -o pool_lv` from all nodes Regards Rafi KC ----- Original Message ----- From: "Strahil Nikolov" <hunter86_bg(a)yahoo.com> To: gluster-users(a)gluster.org Sent: Wednesday, April 10, 2019 2:36:39 AM Subject: [Gluster-users] Gluster snapshot fails Hello Community, I have a problem running a snapshot of a replica 3 arbiter 1 volume. Error: [root@ovirt2 ~]# gluster snapshot create before-423 engine description "Before upgrade of engine from 4.2.2 to 4.2.3" snapshot create: failed: Snapshot is supported only for thin provisioned LV. Ensure that all bricks of engine are thinly provisioned LV. Snapshot command failed Volume info: Volume Name: engine Type: Replicate Volume ID: 30ca1cc2-f2f7-4749-9e2e-cee9d7099ded Status: Started Snapshot Count: 0 Number of Bricks: 1 x (2 + 1) = 3 Transport-type: tcp Bricks: Brick1: ovirt1:/gluster_bricks/engine/engine Brick2: ovirt2:/gluster_bricks/engine/engine Brick3: ovirt3:/gluster_bricks/engine/engine (arbiter) Options Reconfigured: cluster.granular-entry-heal: enable performance.strict-o-direct: on network.ping-timeout: 30 storage.owner-gid: 36 storage.owner-uid: 36 user.cifs: off features.shard: on cluster.shd-wait-qlength: 10000 cluster.shd-max-threads: 8 cluster.locking-scheme: granular cluster.data-self-heal-algorithm: full cluster.server-quorum-type: server cluster.quorum-type: auto cluster.eager-lock: enable network.remote-dio: off performance.low-prio-threads: 32 performance.io-cache: off performance.read-ahead: off performance.quick-read: off transport.address-family: inet nfs.disable: on performance.client-io-threads: off cluster.enable-shared-storage: enable All bricks are on thin lvm with plenty of space, the only thing that could be causing it is that ovirt1 & ovirt2 are on /dev/gluster_vg_ssd/gluster_lv_engine , while arbiter is on /dev/gluster_vg_sda3/gluster_lv_engine. Is that the issue ? Should I rename my brick's VG ? If so, why there is no mentioning in the documentation ? Best Regards, Strahil Nikolov _______________________________________________ Gluster-users mailing list Gluster-users(a)gluster.org https://lists.gluster.org/mailman/listinfo/gluster-users

1 3

Hosted-engine inaccessible
by Tau Makgaile 12 Apr '19

12 Apr '19

Hi, I am currently experiencing a problem with my Hosted-engine. Hosted-engine disconnected after increasing / partition. The increase went well but after some time the hosted-enigine VM disconnected and has since been giving alerts such as* re-initializingFSM*. Though VMs underneth are running, Hosted-engine --vm-status: *"reason": "failed liveliness check", "health": "bad", "vm": "up", "detail"* There is no backup to restore at the moment. I am looking for a way to bring it up without redeploying the hosted engine. Thanks in advance for your help. Kind regards, Tau

4 5

oVirt Node 4.3 Master on fc28
by femi adegoke 12 Apr '19

12 Apr '19

4.3 Master is looking good!! A few questions: - In Step #2: Fqdns: for a 3 host cluster, are we to add the 2nd & 3rd hosts? - In Step #5: Bricks: What effect does the RAID setting have? Enable Dedupe & Compression is new? Configure LV Cache: what do we enter for SSD? What happens if my disks are already all SSD, do I still benefit from using this?

4 11