While looking at libvirt tagged questions on serverfault I saw
someone ask how to indicate that a virtual disk is an SSD rather
than rotating rust.

https://serverfault.com/questions/876467/how-to-add-virtual-storage-as-ssd-in-kvm

IIUC, IDE / SCSI don't really have an explicit concept of a
disk being SSD vs HDD, but they do have a means of reporting
the disk rotation rate and both specify that SSDs should
report RPM==1.

Linux uses this to determine whether to set the 'rotational'
property to 0 for the I/O queue, and also whether to allow
the disk to contribute random entropy (only HDDs contribute).

This felt like something QEMU ought to allow the mgmt application
to set based on the storage it is using to back the virtual block
devices. So this series adds a 'rotation_rate' property to the
SCSI and IDE disks, taking an RPM value per their respective
specifications.

There is no mechanism to report this information to virtio-blk.
We could perhaps argue that people should use virtio-scsi instead,
because fixing virtio-blk would require enhancement to both QEMU
and Linux virtio-blk drivers (and other guest OS drivers too)

I'm unclear if there is anything I should have done wrt the
device migration vmstate when adding this extra field, or if it
is safe to just expect the mgmt app to set the property correctly
on src+dst ?

Daniel P. Berrange (2):
  scsi-disk: support reporting of rotation rate
  ide: support reporting of rotation rate

 hw/ide/core.c             |  1 +
 hw/ide/qdev.c             |  1 +
 hw/scsi/scsi-disk.c       | 20 ++++++++++++++++++++
 include/hw/ide/internal.h |  8 ++++++++
 4 files changed, 30 insertions(+)

-- 
2.13.5

On Wed, Oct 04, 2017 at 12:40:06PM +0100, Daniel P. Berrange wrote:
> While looking at libvirt tagged questions on serverfault I saw
> someone ask how to indicate that a virtual disk is an SSD rather
> than rotating rust.
> 
> https://serverfault.com/questions/876467/how-to-add-virtual-storage-as-ssd-in-kvm
> 
> IIUC, IDE / SCSI don't really have an explicit concept of a
> disk being SSD vs HDD, but they do have a means of reporting
> the disk rotation rate and both specify that SSDs should
> report RPM==1.
> 
> Linux uses this to determine whether to set the 'rotational'
> property to 0 for the I/O queue, and also whether to allow
> the disk to contribute random entropy (only HDDs contribute).
> 
> This felt like something QEMU ought to allow the mgmt application
> to set based on the storage it is using to back the virtual block
> devices. So this series adds a 'rotation_rate' property to the
> SCSI and IDE disks, taking an RPM value per their respective
> specifications.

BTW, to verify these patches there's two ways:

  # smartctl -a /dev/sda | grep Rotation
  Rotation Rate:        15000 rpm

  # smartctl -a /dev/sdb | grep Rotation
  Rotation Rate:        Solid State Device

Before these patches, 'Rotation rate' is not reported by smartctl
at all. With these patches the default value of '0' means nothing
will be reported too. Only if set to a non-zero value will it
be reported.

Or look at kernel queue:

  # cat /sys/block/sda/queue/rotational 
  1

  # cat /sys/block/sdb/queue/rotational 
  0



Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

On 04/10/2017 13:40, Daniel P. Berrange wrote:
> 
> There is no mechanism to report this information to virtio-blk.
> We could perhaps argue that people should use virtio-scsi instead,
> because fixing virtio-blk would require enhancement to both QEMU
> and Linux virtio-blk drivers (and other guest OS drivers too)

I think long-term virtio-blk should only be used for high-performance
scenarios where the guest SCSI layer slows down things sensibly.  So
perhaps virtio-blk should always report itself as non-rotational.

> I'm unclear if there is anything I should have done wrt the
> device migration vmstate when adding this extra field, or if it
> is safe to just expect the mgmt app to set the property correctly
> on src+dst ?

That should be enough, yes.

Paolo