In addition the blockdev props formatter shouldn't even attempt to format the chache (we use a shortcut to add it to all backends since all until now seemed to support it). That way if the nvme device is somewhere in the backing chain where it will skip formatting the cache props too, since we propagate disk cache settings to all layers of the backing chain (explicit cache config is not yet implemented).

Is really cache not supported? Looking into nvme_file_open() I see the following code:


    if (flags & BDRV_O_NOCACHE) {
        if (!s->write_cache_supported) {
            error_setg(errp,
                       "NVMe controller doesn't support write cache configuration");
            ret = -EINVAL;
        } else {
            ret = nvme_enable_disable_write_cache(bs, !(flags & BDRV_O_NOCACHE),
                                                  errp);
        }
        if (ret) {
            goto fail;
        }
    }


So error is reported only if s->write_cache_supported is not set. Looking further it looks like nvme_identify() sets write_cache_supported if underlying NVMe device supports it (based on what NVME_ADM_CMD_IDENTIFY returns).

Bulk update: Move RHEL-AV bugs to RHEL9. If necessary to resolve in RHEL8, then clone to the current RHEL8 release.

Based on the fact that not all NVMe drives reject cache it seems to be a valid configuration.

Unfortunately it doesn't seem simple enough for libvirt to probe the NVMe device to figure out whether cache is supported and thus it's not feasible for us to reimplement the check.

A similar situation is also with the 'io=' setting. Libvirt's XML has only one attribute per disk, but the setting is really per-image, thus libvirt propagates the value for every layer in the backing chain and storage protocol nodes which don't support that setting ignore it. There are few possible scenarios where we could forbid the setting but again it's not really simple and the benefit is questionable.

For now I'm closing this as I don't see a reasonable way forward.