Non, cela fonctionne parfaitement, à minima sur ceux que je connais bien.
Un block-device, virtuel ou non, est vu comme un block device par l'OS et l'aspect Cloud / VM n'y change rien.
Pour parler de ce que je connais bien, un volume EBS sur une instance AWS EC2 utilisant Nitro est exposé comme un disque NVMe et présenté directement aux VMs sur le bus PCIe.

On peut en effet considérer LVM moins utile pour les cas simples, dans la mesure où les systèmes de stockage bloc utilisés dans le cloud publique te permettent de monter un nombre raisonnablement grand de volumes par instance, et de les agrandir à la volée, et de gérer les permissions d'accès aux volumes via le framework de gestion de droit du fournisseur cloud.
Maintenant il y a également d'excellents cas d'usage de LVM sur ces block-devices, par exemple lorsque tu veux conserver la complexité de gestion des volumes au niveau de l'OS et monter différentes partitions avec des options différentes (hardening type ANSSI par exemple).

Sur AWS, la quasi-totalité des AMIs (images système) n'utilisent pas LVM par défaut, mais rien n'empêche d'en construire une, cela fonctionne parfaitement, du temps que la stack de virtualisation arrive à trouver ton boot-loader et que celui-ci parvient à lire un kernel/initrd.

La raison sous-jacente à cette absence quasi-total de LVM pour le volume racine vient assez probablement du fait que les systèmes sont plus souvent considérés comme fongibles dans le cloud que on-prem (et encore, le on-prem est devenu proche), donc on est plus souvent dans un cas où tu automatises l'installation de ton système et quand tu dois le modifier tu en ré-installes un nouveau pour remplacer l'existant plutôt que de le modifier.

Pas plus que dans le cas d'un block-device non cloud, ie non.

Arthur.

P.S.: full disclosure - je suis Specialist SA EC2 / Graviton chez AWS.