Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 2086384

Summary:	Support to list mtdblock, pmem, mmcblk,pktcdvd node devices
Product:	Red Hat Enterprise Linux 9	Reporter:	Han Han <hhan>
Component:	libvirt	Assignee:	Virtualization Maintenance <virt-maint>
libvirt sub component:	General	QA Contact:	yalzhang <yalzhang>
Status:	CLOSED MIGRATED	Docs Contact:
Severity:	unspecified
Priority:	unspecified	CC:	jsuchane, lmen, mprivozn, smitterl, virt-maint, xuzhang
Version:	9.1	Keywords:	MigratedToJIRA, Triaged
Target Milestone:	rc	Flags:	pm-rhel: mirror+
Target Release:	---
Hardware:	x86_64
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-06-30 18:41:59 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Han Han 2022-05-16 03:42:40 UTC

Description of problem:
As subject

Version-Release number of selected component (if applicable):
libvirt-8.3.0-1.el9.x86_64

How reproducible:
100%

Steps to Reproduce:
1. Emulate pmem and mmcblk by QEMU. And check these node devices
i. Start a RHEL9 VM with these XML:
<domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'>
  <maxMemory slots='16' unit='KiB'>4097152</maxMemory>
...
  <cpu mode='host-model' check='partial'>
    <numa>
      <cell id='0' cpus='0-1' memory='2095104' unit='KiB'/>
    </numa>
  </cpu>
...
  <devices>
...
    <memory model='virtio-pmem' access='shared'>
      <source>
        <path>/tmp/virtio_pmem</path>
      </source>
      <target>
        <size unit='KiB'>524288</size>
      </target>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/>
    </memory>
  </devices>
  <qemu:commandline>
    <qemu:arg value='-device'/>
    <qemu:arg value='sdhci-pci,id=sdhci,bus=pci.0,addr=0xf'/>
    <qemu:arg value='-device'/>
    <qemu:arg value='sd-card,drive=mydrive'/>
    <qemu:arg value='-drive'/>
    <qemu:arg value='id=mydrive,if=none,format=raw,file=/tmp/sdcard'/>
  </qemu:commandline>

ii. Check the block:
[root@localhost ~]# lsblk
NAME          MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
mmcblk0       179:0    0   128M  0 disk 
vda           252:0    0    10G  0 disk 
├─vda1        252:1    0     1G  0 part /boot
└─vda2        252:2    0     9G  0 part 
  ├─rhel-root 253:0    0     8G  0 lvm  /
  └─rhel-swap 253:1    0     1G  0 lvm  [SWAP]
pmem0         259:0    0 511.9M  1 disk 

[root@localhost ~]# udevadm info --name mmcblk0
P: /devices/pci0000:00/0000:00:0f.0/mmc_host/mmc0/mmc0:4567/block/mmcblk0
N: mmcblk0
L: 0
S: disk/by-id/mmc-QEMU__0xdeadbeef
E: DEVPATH=/devices/pci0000:00/0000:00:0f.0/mmc_host/mmc0/mmc0:4567/block/mmcblk0
E: DEVNAME=/dev/mmcblk0
E: DEVTYPE=disk
E: DISKSEQ=3
E: MAJOR=179
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=15106162
E: ID_SERIAL=0xdeadbeef
E: ID_NAME=QEMU_
E: DEVLINKS=/dev/disk/by-id/mmc-QEMU__0xdeadbeef
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

[root@localhost ~]# udevadm info --name pmem0
P: /devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/namespace0.0/block/pmem0
N: pmem0
L: 0
E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/ACPI0012:00/ndbus0/region0/namespace0.0/block/pmem0
E: DEVNAME=/dev/pmem0
E: DEVTYPE=disk
E: DISKSEQ=2
E: MAJOR=259
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=14732010
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

iii. Check the node devices:
[root@localhost ~]# virsh nodedev-list --cap storage
block_vda

No mmcblk and peme devices.


2. For mtdblock device, since the kernel config of RHEL9(5.14.0-90.el9.x86_64) is "CONFIG_MTD=m, CONFIG_MTD_BLOCK=m, CONFIG_MTD_RAM not set. It cannot emulated by kernel in RHEL9. So I test it on Fedora rawhide(5.17.4-300.fc36.x86_64, libvirt-8.3.0-1.fc37.x86_64)
i. Emulate mtdblock device
# modprobe mtdram total_size=200 erase_size=100
# modprobe mtdblock

ii. Check mtdblock by lsblk, udev and virsh.
➜  ~ lsblk
NAME      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS
mtdblock0  31:0    0  200K  0 disk 
vda       252:0    0   80G  0 disk 
└─vda1    252:1    0   80G  0 part /
vdb       252:16   0    5G  0 disk /mnt

➜  ~ udevadm info --name mtdblock0                                       
P: /devices/virtual/mtd/mtd0/mtdblock0
M: mtdblock0
R: 0
U: block
T: disk
D: b 31:0
N: mtdblock0
L: 0
Q: 11
E: DEVPATH=/devices/virtual/mtd/mtd0/mtdblock0
E: DEVNAME=/dev/mtdblock0
E: DEVTYPE=disk
E: DISKSEQ=11
E: MAJOR=31
E: MINOR=0
E: SUBSYSTEM=block
E: USEC_INITIALIZED=1724723462880
E: TAGS=:systemd:
E: CURRENT_TAGS=:systemd:

➜  ~ virsh nodedev-list --cap storage         
block_vda_230c9ab9_9ea9_433d_8
block_vdb

No mtdblock listed by virsh.

Actual results:
As above

Expected results:
Libvirt node device could list mtdblock, mmcblk, pmem devices.

Additional info:
See also: Bug 2045953 - 'virsh nodedev-list --cap storage' doesn't list host nvme storage

Comment 1 Han Han 2022-05-16 03:53:29 UTC

For s390 arch, I find dcss and scm block device are enabled in kernel from the RHEL9 s390 kernel build log(kmod dcssblk.ko, scm_block.ko), but none of them is mentioned in libvirt node device codes.
So I guess these block device cannot be listed by libvirt node devices either.
Sebas, could you please help to confirm my guess on s390 machines?
If it is confirmed, you can file a bug to request the node device support of dcss and scm

Comment 2 Han Han 2022-05-17 03:57:42 UTC

pktcdvd is also supported in RHEL9 kernel:
➜  ~ grep pktcdvd /boot/config-`uname -r` -i
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8

Comment 3 Han Han 2022-05-23 06:20:48 UTC

One more block device:  Sony MemoryStickPro block device
➜  ~ grep MSPRO /boot/config-5.14.0-87.el9.x86_64
CONFIG_MSPRO_BLOCK=m

Comment 4 smitterl 2022-07-08 13:44:24 UTC

(In reply to Han Han from comment #1)
> For s390 arch, I find dcss and scm block device are enabled in kernel from
> the RHEL9 s390 kernel build log(kmod dcssblk.ko, scm_block.ko), but none of
> them is mentioned in libvirt node device codes.
> So I guess these block device cannot be listed by libvirt node devices
> either.
> Sebas, could you please help to confirm my guess on s390 machines?
> If it is confirmed, you can file a bug to request the node device support of
> dcss and scm

Sorry for the late answer, we got our feedback from Thomas back in May "both storage types are not supported in KVM and thus I think they are not supported by libvirt."

Comment 5 Michal Privoznik 2023-03-06 15:12:18 UTC

I'm not so sure we want to list everything. I mean, it makes sense to list that types of storage that can be assigned to a guest and fundamentally, virtio-pmem is different. Or is the aim to list whatever 'lsblk' lists?