On Mon, Oct 5, 2020 at 9:06 AM Gianluca Cecchi <gianluca.cec...@gmail.com> wrote: > > On Mon, Oct 5, 2020 at 2:19 AM Nir Soffer <nsof...@redhat.com> wrote: >> >> On Sun, Oct 4, 2020 at 6:09 PM Amit Bawer <aba...@redhat.com> wrote: >> > >> > >> > >> > On Sun, Oct 4, 2020 at 5:28 PM Gianluca Cecchi <gianluca.cec...@gmail.com> >> > wrote: >> >> >> >> On Sun, Oct 4, 2020 at 10:21 AM Amit Bawer <aba...@redhat.com> wrote: >> >>> >> >>> >> >>> >> >>> Since there wasn't a filter set on the node, the 4.4.2 update added the >> >>> default filter for the root-lv pv >> >>> if there was some filter set before the upgrade, it would not have been >> >>> added by the 4.4.2 update. >> >>>> >> >>>> >> >> >> >> Do you mean that I will get the same problem upgrading from 4.4.2 to an >> >> upcoming 4.4.3, as also now I don't have any filter set? >> >> This would not be desirable.... >> > >> > Once you have got back into 4.4.2, it's recommended to set the lvm filter >> > to fit the pvs you use on your node >> > for the local root pv you can run >> > # vdsm-tool config-lvm-filter -y >> > For the gluster bricks you'll need to add their uuids to the filter as >> > well. >> >> vdsm-tool is expected to add all the devices needed by the mounted >> logical volumes, so adding devices manually should not be needed. >> >> If this does not work please file a bug and include all the info to reproduce >> the issue. >> > > I don't know what exactly happened when I installed ovirt-ng-node in 4.4.0, > but the effect was that no filter at all was set up in lvm.conf, and so the > problem I had upgrading to 4.4.2. > Any way to see related logs for 4.4.0? In which phase of the install of the > node itself or of the gluster based wizard is it supposed to run the > vdsm-tool command? > > Right now in 4.4.2 I get this output, so it seems it works in 4.4.2: > > " > [root@ovirt01 ~]# vdsm-tool config-lvm-filter > Analyzing host... > Found these mounted logical volumes on this host: > > logical volume: /dev/mapper/gluster_vg_sda-gluster_lv_data > mountpoint: /gluster_bricks/data > devices: > /dev/disk/by-id/lvm-pv-uuid-5D4JSI-vqEc-ir4o-BGnG-sZmh-ILjS-jgzICr > > logical volume: /dev/mapper/gluster_vg_sda-gluster_lv_engine > mountpoint: /gluster_bricks/engine > devices: > /dev/disk/by-id/lvm-pv-uuid-5D4JSI-vqEc-ir4o-BGnG-sZmh-ILjS-jgzICr > > logical volume: /dev/mapper/gluster_vg_sda-gluster_lv_vmstore > mountpoint: /gluster_bricks/vmstore > devices: > /dev/disk/by-id/lvm-pv-uuid-5D4JSI-vqEc-ir4o-BGnG-sZmh-ILjS-jgzICr > > logical volume: /dev/mapper/onn-home > mountpoint: /home > devices: > /dev/disk/by-id/lvm-pv-uuid-52iT6N-L9sU-ubqE-6vPt-dn7T-W19c-NOXjc7 > > logical volume: /dev/mapper/onn-ovirt--node--ng--4.4.2--0.20200918.0+1 > mountpoint: / > devices: > /dev/disk/by-id/lvm-pv-uuid-52iT6N-L9sU-ubqE-6vPt-dn7T-W19c-NOXjc7 > > logical volume: /dev/mapper/onn-swap > mountpoint: [SWAP] > devices: > /dev/disk/by-id/lvm-pv-uuid-52iT6N-L9sU-ubqE-6vPt-dn7T-W19c-NOXjc7 > > logical volume: /dev/mapper/onn-tmp > mountpoint: /tmp > devices: > /dev/disk/by-id/lvm-pv-uuid-52iT6N-L9sU-ubqE-6vPt-dn7T-W19c-NOXjc7 > > logical volume: /dev/mapper/onn-var > mountpoint: /var > devices: > /dev/disk/by-id/lvm-pv-uuid-52iT6N-L9sU-ubqE-6vPt-dn7T-W19c-NOXjc7 > > logical volume: /dev/mapper/onn-var_crash > mountpoint: /var/crash > devices: > /dev/disk/by-id/lvm-pv-uuid-52iT6N-L9sU-ubqE-6vPt-dn7T-W19c-NOXjc7 > > logical volume: /dev/mapper/onn-var_log > mountpoint: /var/log > devices: > /dev/disk/by-id/lvm-pv-uuid-52iT6N-L9sU-ubqE-6vPt-dn7T-W19c-NOXjc7 > > logical volume: /dev/mapper/onn-var_log_audit > mountpoint: /var/log/audit > devices: > /dev/disk/by-id/lvm-pv-uuid-52iT6N-L9sU-ubqE-6vPt-dn7T-W19c-NOXjc7 > > This is the recommended LVM filter for this host: > > filter = [ > "a|^/dev/disk/by-id/lvm-pv-uuid-52iT6N-L9sU-ubqE-6vPt-dn7T-W19c-NOXjc7$|", > "a|^/dev/disk/by-id/lvm-pv-uuid-5D4JSI-vqEc-ir4o-BGnG-sZmh-ILjS-jgzICr$|", > "r|.*|" ] > > This filter allows LVM to access the local devices used by the > hypervisor, but not shared storage owned by Vdsm. If you add a new > device to the volume group, you will need to edit the filter manually. > > To use the recommended filter we need to add multipath > blacklist in /etc/multipath/conf.d/vdsm_blacklist.conf: > > blacklist { > wwid "Samsung_SSD_850_EVO_500GB_S2RBNXAH108545V" > wwid "Samsung_SSD_850_EVO_M.2_250GB_S24BNXAH209481K" > } > > > Configure host? [yes,NO] > > " > Does this mean that answering "yes" I will get both lvm and multipath related > files modified?
Yes... > > Right now my multipath is configured this way: > > [root@ovirt01 ~]# grep -v "^#" /etc/multipath.conf | grep -v "^ #" | grep > -v "^$" > defaults { > polling_interval 5 > no_path_retry 4 > user_friendly_names no > flush_on_last_del yes > fast_io_fail_tmo 5 > dev_loss_tmo 30 > max_fds 4096 > } > blacklist { > protocol "(scsi:adt|scsi:sbp)" > } > overrides { > no_path_retry 4 > } This file will not change... > [root@ovirt01 ~]# > > with blacklist explicit on both disks but inside different files: > > root disk: > [root@ovirt01 ~]# cat /etc/multipath/conf.d/vdsm_blacklist.conf > # This file is managed by vdsm, do not edit! > # Any changes made to this file will be overwritten when running: > # vdsm-tool config-lvm-filter > > blacklist { > wwid "Samsung_SSD_850_EVO_M.2_250GB_S24BNXAH209481K" Here we will have the second device... > } > [root@ovirt01 ~]# > > gluster disk: > [root@ovirt01 ~]# cat /etc/multipath/conf.d/blacklist.conf > # BEGIN ANSIBLE MANAGED BLOCK > blacklist { > # BEGIN ANSIBLE MANAGED BLOCK sda > wwid "Samsung_SSD_850_EVO_500GB_S2RBNXAH108545V" > # END ANSIBLE MANAGED BLOCK sda > } > # END ANSIBLE MANAGED BLOCK This file will not change, it was created by RHHI deploy, and vdsm knows nothing about it. RHHI should integrate with new vdsm-tool capabilities instead of duplicating the functionality. > [root@ovirt01 ~]# > > > [root@ovirt01 ~]# cat /etc/multipath/wwids > # Multipath wwids, Version : 1.0 > # NOTE: This file is automatically maintained by multipath and multipathd. > # You should not need to edit this file in normal circumstances. > # > # Valid WWIDs: > /Samsung_SSD_850_EVO_500GB_S2RBNXAH108545V/ This file will not be changed by vdsm-tool. multipath manages this file. > [root@ovirt01 ~]# > > and in fact no multipath devices setup due to the blacklist sections for > local disks... Sounds good. > > [root@ovirt01 ~]# multipath -l > [root@ovirt01 ~]# > > Gianluca > _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/privacy-policy.html oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/CXB4U63XJ3YC2PW2I3OD4I77LKI4YGLT/