lvs --config 'devices { filter = [ "a|.*|" ] }'

I see also all the gluster volumes, so I think the update injected the nasty filter.

Possibly during update the command

# vdsm-tool config-lvm-filter -y

was executed and erroneously created the filter?

Anyway remounting read write the root filesystem and removing the filter line from lvm.conf and rebooting worked and 4.4.2 booted ok and I was able to exit global maintenance and have the engine up.

Thanks Amit for the help and all the insights.

Right now only two problems:

1) a long running problem that from engine web admin all the volumes are seen as up and also the storage domains up, while only the hosted engine one is up, while "data" and vmstore" are down, as I can verify from the host, only one /rhev/data-center/ mount:

[root@ovirt01 ~]# df -h
Filesystem                                              Size  Used Avail Use% Mounted on
devtmpfs                                                 16G     0   16G   0% /dev
tmpfs                                                    16G   16K   16G   1% /dev/shm
tmpfs                                                    16G   18M   16G   1% /run
tmpfs                                                    16G     0   16G   0% /sys/fs/cgroup
/dev/mapper/onn-ovirt--node--ng--4.4.2--0.20200918.0+1  133G  3.9G  129G   3% /
/dev/mapper/onn-tmp                                    1014M   40M  975M   4% /tmp
/dev/mapper/gluster_vg_sda-gluster_lv_engine            100G  9.0G   91G   9% /gluster_bricks/engine
/dev/mapper/gluster_vg_sda-gluster_lv_data              500G  126G  375G  26% /gluster_bricks/data
/dev/mapper/gluster_vg_sda-gluster_lv_vmstore            90G  6.9G   84G   8% /gluster_bricks/vmstore
/dev/mapper/onn-home                                   1014M   40M  975M   4% /home
/dev/sdb2                                               976M  307M  603M  34% /boot
/dev/sdb1                                               599M  6.8M  593M   2% /boot/efi
/dev/mapper/onn-var                                      15G  263M   15G   2% /var
/dev/mapper/onn-var_log                                 8.0G  541M  7.5G   7% /var/log
/dev/mapper/onn-var_crash                                10G  105M  9.9G   2% /var/crash
/dev/mapper/onn-var_log_audit                           2.0G   79M  2.0G   4% /var/log/audit
ovirt01st.lutwyn.storage:/engine                        100G   10G   90G  10% /rhev/data-center/mnt/glusterSD/ovirt01st.lutwyn.storage:_engine
tmpfs                                                   3.2G     0  3.2G   0% /run/user/1000
[root@ovirt01 ~]#

I can also wait 10 minutes and no change. The way I use to exit from this stalled situation is power on a VM, so that obviously it fails

and suddenly all the data storage domains are deactivated (from engine point of view, because actually they were not active...):

and I can go in Data Centers --> Default --> Storage and activate "vmstore" and "data" storage domains and suddenly I get them activated and filesystems mounted.

Gianluca