9:35 p.m.
On February 25, 2020 8:18:20 PM GMT+02:00, adrianquintero(a)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(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/HVCYYZSUJ7R...
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