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/
