It is possible for the user to specify the persistent identifier at creation time.  Here's an example of me creating a VDO volume with the persistent identifier pointing to /dev/nvme0n1:

# vdo create --name=vdo1 --device=/dev/disk/by-id/nvme-nvme.8086-50484d42373432363030473234383044474e-494e54454c2053534450454431443438304741-00000001 --vdoLogicalSize=4T
Creating VDO vdo1
Starting VDO vdo1
Starting compression on VDO vdo1
VDO instance 2 volume is ready at /dev/mapper/vdo1

# cat /etc/vdoconf.yml 
####################################################################
# THIS FILE IS MACHINE GENERATED. DO NOT EDIT THIS FILE BY HAND.
####################################################################
config: !Configuration
  vdos:
    vdo1: !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/nvme-nvme.8086-50484d42373432363030473234383044474e-494e54454c2053534450454431443438304741-00000001
      hashZoneThreads: 1
      indexCfreq: 0
      indexMemory: 0.25
      indexSparse: disabled
      indexThreads: 0
      logicalBlockSize: 4096
      logicalSize: 4T
      logicalThreads: 1
      name: vdo1
      physicalSize: 468851544K
      physicalThreads: 1
      readCache: disabled
      readCacheSize: 0M
      slabSize: 2G
      writePolicy: sync
  version: 538380551

I assume the VDO UUID and blkid changes haven't propagated enough by this point for us to be able to just point to /dev/disk/by-uuid/a1b2c3d4-5678-... as the storage device, identifying it by the UUID in the label we put there ourselves...

I think that's probably the right thing down the road, but the support isn't quite there yet.

What does "propagated enough" mean?

Included in RHEL 7.5; publicly released if we care about people testing VDO from GitHub being able to use it; deployed on our testing machines (which AFAIK are still RHEL 7.4).

I could implement it using the VDO UUID with a fallback in case blkid doesn't recognize VDO volumes, but automated testing would then require that we have some test machines with the blkid support and some without.

If the new blkid is in 7.5, and we can deploy it to the test machines, maybe we can get away without the fallback path, which will keep things simpler.

(In reply to Ken Raeburn from comment #5)
> If the new blkid is in 7.5, and we can deploy it to the test machines, maybe
> we can get away without the fallback path, which will keep things simpler.

It is in 7.5.

[root@75Beta ~]# lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sr0            11:0    1 1024M  0 rom  
vda           252:0    0   20G  0 disk 
├─vda1        252:1    0    1G  0 part /boot
└─vda2        252:2    0   19G  0 part 
  ├─rhel-root 253:0    0   17G  0 lvm  /
  └─rhel-swap 253:1    0    2G  0 lvm  [SWAP]
vdb           252:16   0   20G  0 disk 
└─vdo0        253:2    0   16G  0 vdo  

[root@75Beta ~]# dmsetup info vdo0
Name:              vdo0
State:             ACTIVE
Read Ahead:        256
Tables present:    LIVE
Open count:        0
Event number:      0
Major, minor:      253, 2
Number of targets: 1
UUID: VDO-161d5026-c2b6-42cd-9f46-2b34ebf93e3c

[root@75Beta ~]# ls -l /dev/disk/by-uuid/161d5026-c2b6-42cd-9f46-2b34ebf93e3c
lrwxrwxrwx. 1 root root 9 Feb  1 20:21 /dev/disk/by-uuid/161d5026-c2b6-42cd-9f46-2b34ebf93e3c -> ../../vdb

Product Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

*** Bug 1547090 has been marked as a duplicate of this bug. ***

Reproducer from duplicate BZ 1547090:
# vdo create --name vdo0 --device /dev/vgroup0/lvol0
# lvrename vgroup lvol0 lvol1
(/dev/mapper/vdo0 keeps working)
# vdo stop --name vdo0
# vdo start --name vdo0
Starting VDO vdo0
vdo: ERROR - Could not set up device mapper for vdo0
vdo: ERROR - vdodumpconfig: Failed to make FileLayer from '/dev/vgroup0/lvol0' with No such file or directory

I think a warning in the 7.5 documentation along the lines: "if you use a non-persistent device name, then VDO may fail to startup properly in the future if the device name changes. It is recommended that you use a persistent device name." With an example. (If you agree, open a new BZ against the Storage Admin. Guide.)

Out of curiosity, in the longer-term (7.6+), will you accept whatever device name the user enters, and replace it in the config file with the VDO UUID? 

Whatever the change in behavior in 7.6, it may need to be documented. 

Do we also need to tell people how to check, and repair, their old config file? (Probably appropriate in a kbase, for CEE.) 

Tom

Yes, I think that sounds good.  I will open a BZ against the storage admin guide,

And yes, I believe the intent is to end up allowing both a device and a UUID in the configuration, to allow for backwards compatibility.

We generally advise that it is super dangerous to hand-edit the config file, but there are a couple of situations where it is necessary.  This is one of those.

(In reply to Andy Walsh from comment #16)

> And yes, I believe the intent is to end up allowing both a device and a UUID
> in the configuration, to allow for backwards compatibility.

And if the user provides a non-persistent device name, will you convert it to a UUID before writing it to the config. file? (Perhaps with a message displayed, indicating that the conversion has been done, and why?)  (I have no idea whether this is appropriate or feasible in this context, but it seems quite important to me to avoid non-persistent device names in the config. file.)

Tom

Tested on:
RHEL-7.6-20180626.0
kernel-3.10.0-915.el7
kmod-vdo-6.1.1.99-1.el7
vdo-6.1.1.99-2.el7

# vdo create --name vdo --device /dev/mapper/vg-lv0  --verbose
Creating VDO vdo
    grep MemAvailable /proc/meminfo
    pvcreate -qq --test /dev/mapper/vg-lv0
    modprobe kvdo
    vdoformat --uds-checkpoint-frequency=0 --uds-memory-size=0.25 /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
    vdodumpconfig /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
Starting VDO vdo
    dmsetup status vdo
    grep MemAvailable /proc/meminfo
    modprobe kvdo
    vdodumpconfig /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
    dmsetup create vdo --uuid VDO-07e1894c-6327-40fb-b8d2-a2944c38f4e2 --table '0 4278400280 vdo /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum 4096 disabled 0 32768 16380 on auto vdo ack=1,bio=4,bioRotationInterval=64,cpu=2,hash=1,logical=1,physical=1'
    dmsetup status vdo
Starting compression on VDO vdo
    dmsetup message vdo 0 compression on
    dmsetup status vdo
VDO instance 4 volume is ready at /dev/mapper/vdo
# lvrename vg lv0 lv1
  Renamed "lv0" to "lv1" in volume group "vg"
# vdo stop --name vdo
Stopping VDO vdo
# vdo start --name vdo
Starting VDO vdo
Starting compression on VDO vdo
VDO instance 5 volume is ready at /dev/mapper/vdo

/var/log/messages:

[165080.993051] kvdo4:dmsetup: starting device 'vdo'
[165081.017817] kvdo4:dmsetup: underlying device, REQ_FLUSH: not supported, REQ_FUA: not supported
[165081.060621] kvdo4:dmsetup: Using write policy sync automatically.
[165081.088289] kvdo4:dmsetup: zones: 1 logical, 1 physical, 1 hash; base threads: 5
[165081.297119] kvdo4:journalQ: VDO commencing normal operation
[165081.322760] kvdo4:dmsetup: uds: kvdo4:dedupeQ: creating index: dev=/dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum offset=4096 size=2781704192
uds: kvdo4:dedupeQ: Using 6 indexing zones for concurrency.

[165081.421903] Setting UDS index target state to online
[165081.445848] kvdo4:dmsetup: device 'vdo' started
[165081.466724] kvdo4:dmsetup: resuming device 'vdo'
[165081.487901] kvdo4:dmsetup: device 'vdo' resumed
[165081.528959] kvdo4:packerQ: compression is enabled
[165110.624257] kvdo4:dmsetup: suspending device 'vdo'
[165110.649965] kvdo4:dmsetup: device 'vdo' suspended
[165110.675696] kvdo4:dmsetup: stopping device 'vdo'
[165110.699564] kvdo4:dmsetup: uds: kvdo4:dedupeQ: index_0: beginning save (vcn 4294967295)

[165110.736062] Setting UDS index target state to closed
[165110.953293] kvdo4:dmsetup: device 'vdo' stopped
[165116.217691] kvdo5:dmsetup: starting device 'vdo'
[165116.240626] kvdo5:dmsetup: underlying device, REQ_FLUSH: not supported, REQ_FUA: not supported
[165116.285253] kvdo5:dmsetup: Using write policy sync automatically.
[165116.314339] kvdo5:dmsetup: zones: 1 logical, 1 physical, 1 hash; base threads: 5
[165116.539228] kvdo5:journalQ: VDO commencing normal operation
[165116.565959] kvdo5:dmsetup: uds: kvdo5:dedupeQ: loading or rebuilding index: dev=/dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum offset=4096 size=2781704192
uds: kvdo5:dedupeQ: Using 6 indexing zones for concurrency.

[165116.674778] Setting UDS index target state to online
[165116.699149] kvdo5:dmsetup: device 'vdo' started
[165116.720776] kvdo5:dmsetup: resuming device 'vdo'
[165116.742984] kvdo5:dmsetup: device 'vdo' resumed
[165116.790438] uds: kvdo5:dedupeQ: kvdo5:packerQ: compression is enabled

[165116.821317] read index page map, last update 0
[165116.843876] uds: kvdo5:dedupeQ: index_0: loaded index from chapter 0 through chapter 0

# cat /etc/vdoconf.yml
####################################################################
# THIS FILE IS MACHINE GENERATED. DO NOT EDIT THIS FILE BY HAND.
####################################################################
config: !Configuration
  vdos:
    vdo: !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/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
      hashZoneThreads: 1
      indexCfreq: 0
      indexMemory: 0.25
      indexSparse: disabled
      indexThreads: 0
      logicalBlockSize: 4096
      logicalSize: 2139200140K
      logicalThreads: 1
      name: vdo
      physicalSize: 2097164M
      physicalThreads: 1
      readCache: disabled
      readCacheSize: 0M
      slabSize: 2G
      writePolicy: auto
  version: 538380551

VDO now uses more persistent name by finding the /dev/disk/by-id and operating with that name.

note: other from /dev/disk/by-* work too:
# vdo create --name vdo --device /dev/disk/by-id/dm-uuid-LVM-syPqXkYYvJ7C9n9iiMsBvvb2C1BoIPMPgaVHqogJfpgKDFSJqNEG5qfHIJCIzdum
Creating VDO vdo
Starting VDO vdo
Starting compression on VDO vdo
VDO instance 6 volume is ready at /dev/mapper/vdo
# vdo create --name vdo --device /dev/disk/by-path/ip-10.37.151.6\:3260-iscsi-iqn.2001-05.com.equallogic\:0-af1ff6-6db5d9bd9-f7c9f42596f59bfb-vdo-general-lun-0
Creating VDO vdo
Starting VDO vdo
Starting compression on VDO vdo
VDO instance 7 volume is ready at /dev/mapper/vdo

*** Bug 1612781 has been marked as a duplicate of this bug. ***

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2018:3094