Sergey Levitskiy <sergey.levits...@autodesk.com> wrote: > Here it is the logic. > 1. Default value is taken from a global configuration > vmware.root.disk.controller > 2. To override add the same config to template or VM (starting from 4.10 > UI allows adding advanced settings to templates and/or VMs). If added to > a template all VMs deployed from it will inherit this value. If added to > VM and then template is created it will also inherits all advanced > settings. >
Excellent, thanks. Do you happen to know where this is stored in the database? Thanks again! > > > > On 2/21/17, 7:06 PM, "Nathan Johnson" <njohn...@ena.com> wrote: > > 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
