RFE: Add an option to enable virtio-scsi for new Nova instances by default

[s10]

Description
===========

Currently virtio-scsi is used only for libvirt instances created from the images with properties hw_scsi_model=virtio-scsi and hw_disk_bus=scsi set or from the volumes with the same image metadata.

What is requested: config option in [libvirt] section of the nova.conf to enable virtio-scsi for all new instances by default, even if hw_scsi_model and hw_disk_bus properties for the image is not set.

Why: we want virtio-scsi to be enabled for VMs created from users images even if they don't set this property explicitly, because we want to have most of the vms be able to issue BLKDISCARD with fstrim.

[Takashi Natsume (natsume-takashi)]

A blueprint should be create.

[s10 (vlad-esten)]

Blueprint https://blueprints.launchpad.net/nova/+spec/virtio-scsi-by-default has been created.

[sean mooney (sean-k-mooney)]

this is really a feature request not a bug.

part of the feature has been addressed by a different bluepint but the config option to enable this by defualt is still outstanding
as such im lieave this open to tack the config change.

[Stephen Finucane (stephenfinucane)]

While the issue you highlight here is real, this wouldn't be a good solution. The primary issue with this approach is the same issue we have with the '[libvirt] rx_queue_size' and '[libvirt] tx_queue_size' - namely that it can break live migration as two hosts with different values will result in a change in the instance XML. If we were to take this approach, we'd have to store the information as part of the instance and we don't have a way to do this other than via the flavor or image metadata. As such, I'm closing this as WONTFIX.

With that said, we do recognize that there is a definite usability issue here. For context, the libosinfo integration in the libvirt driver [1] was supposed to resolve this kind of issue for us but the implementation of that feature is fundamentally broken and it will probably be ripped out in a future release. We're now working on an improved solution to this broader issue, but it will take a different form to this.

[1] https://specs.openstack.org/openstack/nova-specs/specs/liberty/approved/libvirt-hardware-policy-from-libosinfo.html

[Jan Graichen (jgraichen)]

> While the issue you highlight here is real, this wouldn't be a good solution. The primary issue with this approach is the same issue we have with the '[libvirt] rx_queue_size' and '[libvirt] tx_queue_size' - namely that it can break live migration as two hosts with different values will result in a change in the instance XML. If we were to take this approach, we'd have to store the information as part of the instance and we don't have a way to do this other than via the flavor or image metadata. As such, I'm closing this as WONTFIX.

How does this differ from 'hw_machine_type' that has a default in 'nova.conf' and is remembered? Can this wish be reconsidered, since when users can upload their own images, everything will differ strongly due to a dozen "required" image properties for a modern VM?

[sean mooney (sean-k-mooney)]

hw_machine_type is recored in teh instace_system_metadata table as if it was set in the image to resovel the migration issue.

before that you were expected to use hostaggrates or similar to portion your cloud if you used different values.

virtio-blk support BLKDISCARD aka fstrim for what its worth.

it was added after the support was added to virtio-scsi but it has been there for a long time
 so supporting trim is not a valid reason to change our default form virtio-blk as it support trim also.

i will note that if you are testing on an rpm distro with the rhel/centso 7 PC machine type virtio-blk is not supported because of the use of that downstream machine type. on ubunutu/debian the PC machine type support trim with virtio-blk
on centos/rhel you need q35 for trim to work with virtio-blk.