Maybe this is a good opportunity to discuss modernizing the OS selections so that drivers (and other features) could be selectable per OS.
Thoughts? ________________________________ From: Syed Ahmed <sah...@cloudops.com> Sent: Tuesday, January 24, 2017 10:46 AM To: dev@cloudstack.apache.org Cc: Simon Weller Subject: Re: Adding VirtIO SCSI to KVM hypervisors To maintain backward compatibility we would have to add a config option here unfortunately. I do like the idea however. We can make the default VirtIO ISCSI and keep the VirtIO-blk as an alternative for existing installations. On Mon, Jan 23, 2017 at 8:05 AM, Wido den Hollander <w...@widodh.nl<mailto:w...@widodh.nl>> wrote: > Op 21 januari 2017 om 23:50 schreef Wido den Hollander > <w...@widodh.nl<mailto:w...@widodh.nl>>: > > > > > > Op 21 jan. 2017 om 22:59 heeft Syed Ahmed > > <sah...@cloudops.com<mailto:sah...@cloudops.com>> het volgende geschreven: > > > > 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? > > > > Even a global setting would be a bit of work and hacky as well. > > I do not see any reason to keep VirtIO, it os just that devices will be named > sdX instead of vdX in the guest. To add, the Qemu wiki [0] says: "A virtio storage interface for efficient I/O that overcomes virtio-blk limitations and supports advanced SCSI hardware." At OpenStack [1] they also say: "It has been designed to replace virtio-blk, increase it's performance and improve scalability." So it seems that VirtIO is there to be removed. I'd say switch to VirtIO SCSI at version 5.X? :) Wido [0]: http://wiki.qemu.org/Features/VirtioSCSI [1]: https://wiki.openstack.org/wiki/LibvirtVirtioScsi > > That might break existing Instances when not using labels or UUIDs in the > Instance when mounting. > > Wido > > > > >> On Sat, Jan 21, 2017 at 4:22 PM, Simon Weller > >> <swel...@ena.com<mailto: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<tel:615-312-6068> <(615)%20312-6068> > >> > >> > >> -----Original Message----- > >> *From:* Wido den Hollander [w...@widodh.nl<mailto:w...@widodh.nl>] > >> *Received:* Saturday, 21 Jan 2017, 2:56PM > >> *To:* Syed Ahmed [sah...@cloudops.com<mailto:sah...@cloudops.com>]; > >> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org> [ > >> dev@cloudstack.apache.org<mailto: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<mailto: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<mailto: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<mailto: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 > >>>> > >>
