On February 25, 2020 8:18:20 PM GMT+02:00, adrianquint...@gmail.com wrote: >Strahil, >In our case the VDO was created during oVirt HCI setup. So I am trying >to determine how it gets mounted > >As far as I can tell this is the config is as follows: > > >[root@host1 ~]# vdo printConfigFile >config: !Configuration > vdos: > vdo_sdc: !VDOService > _operationState: finished > ackThreads: 1 > activated: enabled > bioRotationInterval: 64 > bioThreads: 4 > blockMapCacheSize: 128M > blockMapPeriod: 16380 > compression: enabled > cpuThreads: 2 > deduplication: enabled > device: /dev/disk/by-id/scsi-3600508b1001cd70935270813aca97c44 > hashZoneThreads: 1 > indexCfreq: 0 > indexMemory: 0.25 > indexSparse: disabled > indexThreads: 0 > logicalBlockSize: 512 > logicalSize: 7200G > logicalThreads: 1 > name: vdo_sdc > physicalSize: 781379416K > physicalThreads: 1 > readCache: enabled > readCacheSize: 20M > slabSize: 32G > writePolicy: auto > version: 538380551 >filename: /etc/vdoconf.yml > > > >[root@host1 ~]# lsblk /dev/sdc >NAME MAJ:MIN RM SIZE RO TYPE >MOUNTPOINT >sdc 8:32 0 745.2G 0 disk >├─3600508b1001cd70935270813aca97c44 253:6 0 745.2G 0 mpath >└─vdo_sdc 253:21 0 7T 0 vdo >└─gluster_vg_sdc-gluster_lv_data 253:22 0 7T 0 lvm >/gluster_bricks/data > >I know that vdo_sdc is the TYPE="LVM2_member", this from /etc/fstab >entries: >/dev/mapper/vdo_sdc: UUID="gsaPfw-agoW-HZ3o-ly0W-wjb3-YqvL-266SnR" >TYPE="LVM2_member" >/dev/mapper/gluster_vg_sdc-gluster_lv_data: >UUID="8a94b876-baf2-442c-9e7f-6573308c8ef3" TYPE="xfs" > > --- Physical volumes --- > PV Name /dev/mapper/vdo_sdc > PV UUID gsaPfw-agoW-HZ3o-ly0W-wjb3-YqvL-266SnR > PV Status allocatable > Total PE / Free PE 1843199 / 0 > > > > >Am am trying to piece things together, I am doing more research on VDO >in an HCI oVirt setup. > >In the meantime any help is welcome. > >Thanks again, > >Adrian > >_______________________________________________ >Users mailing list -- users@ovirt.org >To unsubscribe send an email to users-le...@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/HVCYYZSUJ7RCRMKZLMUCTU537VFYCD76/
Hi Adrian, It seems that /dev/sdc (persistent name /dev/disk/by-id/scsi-3600508b1001cd70935270813aca97c44) is a PV in Volume Group 'gluster_vg_sdc' and the LV 'gluster_lv_data' is mounted as your brick . So you have: Gluster Brick gluster_lv_data -> LV gluster_vg_sdc -> VG gsaPfw-agoW-HZ3o-ly0W-wjb3-YqvL-266SnR -> PV's UUID /dev/disk/by-id/scsi-3600508b1001cd70935270813aca97c44 -> multipath with 1 leg /dev/sdc -> block device Note: You should avoid using multipath for local drvices. In order to do that , you can put the following in your /etc/multipath.conf to prevent vdsm from modifying it: # VDSM PRIVATE And you should blacklist the wwid: blacklist { wwid 3600508b1001cd70935270813aca97c44 } To verify the multipath.conf run: multipath -v3 and check for any errors . Once you modify /etc/multupath.conf and you verified it with 'multipath -v3' , you should update the initramfs: 'dracut -f' Best Regards, Strahil Nikolov _______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/LZBOG3DYJLUYYUV4QR6ZMOL5TRB4BWE3/