Sergey Levitskiy <sergey.levits...@autodesk.com> wrote: > On vmware rootdiskcontroller is passed over to the hypervisor in VM start > command. I know for the fact that the following rootdiskcontroller option > specified in template/vm details work fine: > ide > scsi > lsilogic > lsilogic1068 > > In general, any scsi controller option that vmware recognizes should work. > > Thanks, > Sergey
Thanks Sergey! So do you happen to know where on the management server side the determination is made as to which rootDiskController parameter to pass? > > > On 2/21/17, 6:13 PM, "Nathan Johnson" <njohn...@ena.com> wrote: > > Wido den Hollander <w...@widodh.nl> wrote: > >>> Op 25 januari 2017 om 4:44 schreef Simon Weller <swel...@ena.com>: >>> >>> >>> Maybe this is a good opportunity to discuss modernizing the OS >>> selections so that drivers (and other features) could be selectable per >>> OS. >> >> That seems like a good idea. If you select Ubuntu 16.04 or CentOS 7.3 >> then for example it will give you a VirtIO SCSI disk on KVM, anything >> previous to that will get VirtIO-blk. > > So one thing I noticed, there is a possibility of a rootDiskController > parameter passed to the Start Command. So this means that the Management > server could control whether to use scsi or virtio, assuming I’m reading > this correctly, and we shouldn’t necessarily have to rely on the os type > name inside the agent code. From a quick glance at the vmware code, it > looks like maybe they already use this parameter? It would be great if > someone familiar with the vmware code could chime in here. > > Thanks, > > Nathan > > > >> Wido >> >>> 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 > > > Nathan Johnson > R&D Engineer > > > > 618 Grassmere Park Drive, Suite 12 > Nashville, TN 37211 > General Office: 615-312-6000 > > website | blog | support
