Summary

Cloud Hypervisor does not expose the rotation_rate configuration field for virtio-blk devices. As a result, guest operating systems (notably Windows) cannot determine the disk media type and default to classifying all virtio-blk disks as HDD.

Problem

When running Windows VMs with virtio-blk disks (including vhost-user-blk backed by NVMe/SSD storage), Windows reports:

• Media Type: HDD
• Bus Type: SCSI

This happens because the VirtIO block device does not advertise the rotation rate, so Windows assumes the worst case (rotational disk). This affects:

• Guest OS I/O scheduling decisions (HDD vs SSD optimizations)
• User-visible disk information in Device Manager / Get-PhysicalDisk
• Applications that check media type for behavior (e.g., defragmentation, database engines)

VirtIO Specification

The VirtIO 1.2+ specification defines rotation_rate in the block device configuration (section 5.2.4):

A rotation_rate of 1 indicates a non-rotational device (SSD). A value of 0 means not reported. Other values indicate the rotation rate in RPM.

This follows the same semantics as ATA IDENTIFY DEVICE word 217.

The feature is gated by the VIRTIO_BLK_F_ROTATION_RATE feature bit.

Prior Art

QEMU added rotation_rate support for virtio-blk in v7.0 (2022):

• Commit: qemu/qemu@9da1b37546a5
• Usage: -device virtio-blk-pci,rotation_rate=1 (1 = SSD)

Proposed Solution

Add an optional rotation_rate field to DiskConfig:

# openapi schema
rotation_rate:
  type: integer
  format: int16
  default: 0

And negotiate VIRTIO_BLK_F_ROTATION_RATE (feature bit 22) when rotation_rate is set to a non-zero value.

Use Case

We run Cloud Hypervisor VMs with vhost-user-blk disks backed by SPDK + NVMe storage. Being able to set rotation_rate: 1 would allow Windows (and Linux) guests to correctly identify the disks as SSDs.