Would like to see this as well. Also, would this be an enabler for other activities such as booting from a snapshot with a grub menu item?

This would be a great feature allowing RHEL 7 to use only LVM and no old-school partitions.

This would provide much greater flexibility with disk imaging and our own RHEL cloud images which currently do not use lvm for /dev/sda.  So if I deploy a cloud image, I cannot easily resize the disk limiting my flexibility in use the cloud image as a gold image foundation for my deployments.

Deferring to RHEL 7.5.

> This would provide much greater flexibility with disk imaging and our own RHEL 
> cloud images which currently do not use lvm for /dev/sda.  So if I deploy a 
> cloud image, I cannot easily resize the disk limiting my flexibility in use the 
> cloud image as a gold image foundation for my deployments.

I can understand the limitation here, in terms of conventional partitions not allowing straightforward resize, but it's not quite clear to me why being able to place /boot on LVM2 would fix it?

What's the restriction that prevents the cloud images from using LVM devices on sda in this scenario? (with a conventional partition for /boot as in a regular installation).

We would like to add more boot time features, like booting to a snapshot (or group of snapshots); but eliminating /boot is a tall order - especially with UEFI booting.  This may never happen and certainly won't happen in RHEL7.

Currently I need two block devices to setup a VM.
One as a PV for LVM (without partioning for resize reasoning) and one only for /boot.
Would be a bit easier, if I only need one block device per VM.

(In reply to Christoph Karl from comment #16)
> Currently I need two block devices to setup a VM.
> One as a PV for LVM (without partioning for resize reasoning) and one only
> for /boot.
> Would be a bit easier, if I only need one block device per VM.

RHEL7 and 8 can still be installed with "everything on one partition", 
I think you are referring to that.

$ cat /proc/partitions 
major minor  #blocks  name

 253        0  150994944 vda
 253        1    8388608 vda1
  11        0    1048575 sr0

Currently I have:
>lsblk                                                                                               
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT                                                    
vda           252:0    0    1G  0 disk 
└─vda1        252:1    0 1023M  0 part /boot
vdb           252:16   0   50G  0 disk 
├─rhel-root   253:0    0   40G  0 lvm  /
└─rhel-lvlogs 253:1    0    2G  0 lvm  /logs

Two block devices: vda und vdb.
The PV on vdb must be without partitioning so I can resize the PV.

I want to have:
>lsblk                                                                                               
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT                                                    
vda           252:0    0   50G  0 disk 
├─rhel-root   253:0    0   40G  0 lvm  /
└─rhel-lvlogs 253:1    0    2G  0 lvm  /logs

Only one block device: vda
Reasoning:
*) Only one block device per VM
*) I can online-resize any filesystem in this VM

This would also be OK:
>lsblk                                                                                               
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT                                                    
vda           252:0    0   50G  0 disk 
├─rhel-root   253:0    0   40G  0 lvm  /
├─rhel-boot   253:1    0 1023M  0 lvm  /boot
└─rhel-lvlogs 253:2    0    2G  0 lvm  /logs

Both of the variants you aim at have /boot on LVM, which will for the time
being not become supported, the bugzilla state reflects this.

The next best thing for you might be:
- to have a single blockdevice into the guest
- to have /boot on a partition (which is not resizable in very
  flexible ways, so the size should be chosen carefully)
- to have a further partition, and inside LVM.
  In case you extend the blockdevice in the future, you can
  just add a further partition and use it to extend the VG.
  Alternatively, you can consider to extend the partition 
  and resize the existing PV.

$ lsblk
NAME                   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda                    252:0    0   72G  0 disk 
├─vda1                 252:1    0    1G  0 part /boot
└─vda2                 252:2    0   71G  0 part 
  └─rhel_rhel8u2b-root 253:0    0   45G  0 lvm  /

AFAIK "adding further partitions" and "extending a partition" are not supported:
https://access.redhat.com/solutions/199573

I see this as a feature request not as a bug report.
Currently I stick to two block devices.

I think the bugzilla refers to resizing of a partition which is in use.

Following 2 variants should still be open:

- If really / of the guest should be resized (low chances this is
  required, I think), then one could boot a rescue system and
  do an offline resize of the partition.
- When the underlying blockdevice got enlarged, one could still
  add an additional partition, use pvcreate, extend an LVM volume
  and with this take usage of the additional space