Uploaded image for project: 'OpenShift Virtualization'
  1. OpenShift Virtualization
  2. CNV-60963

R&D: Report VMs with block size incongruence

XMLWordPrintable

    • report-block-size-incongruence-R&D
    • Product / Portfolio Work
    • Hide
      • Research how we can detect block size issues when starting a VM
      • Handle storage migration cases
      • KubeVirt PoC including alerting
      • Customer-visible collateral about the performance impact of block size mismatches
      • QE will join dev to begin understanding this new feature
      • no-doc
      • no-ux
      Show
      Research how we can detect block size issues when starting a VM Handle storage migration cases KubeVirt PoC including alerting Customer-visible collateral about the performance impact of block size mismatches QE will join dev to begin understanding this new feature no-doc no-ux
    • Green
    • VIRTSTRAT-485 - Report VMs with block size incongruence
    • VIRTSTRAT-485Report VMs with block size incongruence
    • 67% To Do, 33% In Progress, 0% Done
    • dev-ready, doc-ready, po-ready, qe-ready, ux-ready
    • Hide

      2025-10-06:
      Need to understand how serious of a performance impact qemu block size emulation has on IO performance...

      Show
      2025-10-06: Need to understand how serious of a performance impact qemu block size emulation has on IO performance...

      Goal

      Historically 512 bytes was the standard block size used by the vast majority of storage systems and remains the default today. Some storage (eg. Portworx block storage) use a larger block size. Ordinarily a guest which writes smaller blocks than the storage expects will get IO errors but qemu handles this by converting guest IO requests into host IO requests that are suitable for the storage. This situation results in degraded performance because qemu will need to perform more IO and the guest is not taking advantage of the larger block size.

      Block size incongruence is hard for a VM user to detect and it can only be fixed with user intervention (reinstall the VM OS or relocate the VM to different storage).

      The goal of this epic is to detect storage incongruence from qemu/libvirt and convey it to the VM owner via an alert. A runbook should be provided to advice the VM owner of the performance impact and the steps that can be taken to remediate.

      User Stories

      • As a VM owner I want to know if my VM has block size incongruence and what I should do to correct it.
      • As a VM owner I expect my VM to function correctly (understanding there will be a performance penalty) when it has block size incongruence.
      • As a VM owner I want the discard granularity to be configured correctly without my intervention. I realize that discard granularity cannot be changed once the VM starts so if a storage migration causes the current setting to be incorrect I want it to be fixed automatically upon the next VM restart.

      Non-Requirements

      • We will not ship golden images that use block sizes other then 512 bytes.
      • We will not proactively report the preferred block size of storage in the OCP cluster.

      Notes

      Discard granularity can be checked as follows:

      • Determine the block device for the image file (e.g. stat(2) fields).
      • If /sys/dev/block/<major>:<minor>/queue/discard_granularity == QEMU --device virtio-blk-pci|scsi-hd,logical_block_size parameter (defaults to 512 if you didn't set it), then everything is okay.
      • Otherwise discard_granularity needs to be set explicitly -> notify user.

      Looking for an event or something from libvirt that can help us to detect when the VM is using a logical block size that is different from the underlying storage.

              rh-ee-aaloni Adi Aloni
              alitke@redhat.com Adam Litke
              Jose Manuel Castano Jose Manuel Castano
              Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

                Created:
                Updated: