Exposing this via an API would be tricky but it can definitely be added as a cluster-wide or a global setting in my opinion. By enabling that, all the instances would be using VirtIO SCSI. Is there a reason you'd want some instances to use VirtIIO and others to use VirtIO SCSI?
On Sat, Jan 21, 2017 at 4:22 PM, Simon Weller <swel...@ena.com> wrote: > For the record, we've been looking into this as well. > Has anyone tried it with Windows VMs before? The standard virtio driver > doesn't support spanned disks and that's something we'd really like to > enable for our customers. > > > > Simon Weller/615-312-6068 <(615)%20312-6068> > > > -----Original Message----- > *From:* Wido den Hollander [w...@widodh.nl] > *Received:* Saturday, 21 Jan 2017, 2:56PM > *To:* Syed Ahmed [sah...@cloudops.com]; dev@cloudstack.apache.org [ > dev@cloudstack.apache.org] > *Subject:* Re: Adding VirtIO SCSI to KVM hypervisors > > > > Op 21 januari 2017 om 16:15 schreef Syed Ahmed <sah...@cloudops.com>: > > > > > > Wido, > > > > Were you thinking of adding this as a global setting? I can see why it > will > > be useful. I'm happy to review any ideas you might have around this. > > > > Well, not really. We don't have any structure for this in place right now > to define what type of driver/disk we present to a guest. > > See my answer below. > > > Thanks, > > -Syed > > On Sat, Jan 21, 2017 at 04:46 Laszlo Hornyak <laszlo.horn...@gmail.com> > > wrote: > > > > > Hi Wido, > > > > > > If I understand correctly from the documentation and your examples, > virtio > > > provides virtio interface to the guest while virtio-scsi provides scsi > > > interface, therefore an IaaS service should not replace it without user > > > request / approval. It would be probably better to let the user set > what > > > kind of IO interface the VM needs. > > > > > You'd say, but we already do those. Some Operating Systems get a IDE disk, > others a SCSI disk and when Linux guest support it according to our > database we use VirtIO. > > CloudStack has no way of telling how to present a volume to a guest. I > think it would be a bit to much to just make that configurable. That would > mean extra database entries, API calls. A bit overkill imho in this case. > > VirtIO SCSI is supported by all Linux distributions for a very long time. > > Wido > > > > Best regards, > > > Laszlo > > > > > > On Fri, Jan 20, 2017 at 10:21 PM, Wido den Hollander <w...@widodh.nl> > > > wrote: > > > > > > > Hi, > > > > > > > > VirtIO SCSI [0] has been supported a while now by Linux and all > kernels, > > > > but inside CloudStack we are not using it. There is a issue for this > [1]. > > > > > > > > It would bring more (theoretical) performance to VMs, but one of the > > > > motivators (for me) is that we can support TRIM/DISCARD [2]. > > > > > > > > This would allow for RBD images on Ceph to shrink, but it can also > give > > > > back free space on QCOW2 images if quests run fstrim. Something all > > > modern > > > > distributions all do weekly in a CRON. > > > > > > > > Now, it is simple to swap VirtIO for VirtIO SCSI. This would however > mean > > > > that disks inside VMs are then called /dev/sdX instead of /dev/vdX. > > > > > > > > For GRUB and such this is no problems. This usually work on UUIDs > and/or > > > > labels, but for static mounts on /dev/vdb1 for example things break. > > > > > > > > We currently don't have any configuration method on how we want to > > > present > > > > a disk to a guest, so when attaching a volume we can't say that we > want > > > to > > > > use a different driver. If we think that a Operating System supports > > > VirtIO > > > > we use that driver in KVM. > > > > > > > > Any suggestion on how to add VirtIO SCSI support? > > > > > > > > Wido > > > > > > > > > > > > [0]: http://wiki.qemu.org/Features/VirtioSCSI > > > > [1]: https://issues.apache.org/jira/browse/CLOUDSTACK-8239 > > > > [2]: https://issues.apache.org/jira/browse/CLOUDSTACK-8104 > > > > > > > > > > > > > > > > -- > > > > > > EOF > > > >
