I don't think this should be tied to the template, but rather the instance/disk. A template could of course specify it's preferred controller.
I don't have a use case for it, but you could potentially want to use different controllers for different disks. E.g. your ROOT-volume might be on a high end SAN you want to utilize with PV-driver, whilst your DATA-volume might be on an old NFS solution where you'll live fine with the SAS or Parallel driver. However, for the first release the most important part is that a selection gets introduced. Currently you cannot install Windows 8.1 or Windows 2012 R2 on VMware with CloudStack, which is a showstopper for many (for us - so much that we changed hypervisor). -- Erik On Mon, Feb 17, 2014 at 6:42 AM, Alex Huang <alex.hu...@citrix.com> wrote: > Sateesh, > > I think if you want to do this then it points to a larger change to > templates. Today, the templates carry no meta information. This means > templates should carry meta information regarding the os image and how to > support it. This should not specifically target vmware. It can benefit > all other hypervisors. I know Anthony's also been working on something > similar for XenServer. I suggest you guys get together and think about the > right approach to abstract this and how to pass this information to the > hypervisor from the template. > > --Alex > > > -----Original Message----- > > From: Sateesh Chodapuneedi [mailto:sateesh.chodapune...@citrix.com] > > Sent: Sunday, February 16, 2014 8:48 PM > > To: dev@cloudstack.apache.org > > Subject: [PROPOSAL] Granular Controller Support in CloudStack over > > VMware deployments > > > > Hi, > > > > I would like to add support for granular disk controller support for > CloudStack > > over VMware deployments. > > > > To access virtual disks, CD/DVD-ROM, and SCSI devices, a virtual machine > > uses storage controllers. > > > > Virtual storage controllers appear to a virtual machine as different > types of > > controllers of type IDE or SCSI. Further SCSI controllers can be > classified into 4 > > sub types, as below > > BusLogic Parallel > > LSI Logic Parallel, > > LSI Logic SAS > > VMware Paravirtual SCSI > > > > Currently CloudStack supports following combinations only. > > DATA volumes - SCSI controller (LSI Logic Parallel) - Hard coded in > source > > code, no option for user to edit/choose the controller type > > ROOT volumes - IDE or SCSI (LSI Logic Parallel) - Baed on value of > global > > configuration parameter "vmware.root.disk.controller" > > > > Currently the instances are deployed with the the LSI Parallel > controller type. > > This might result in failure to boot when attempting to deploy templates > that > > use the LSI SAS controller. > > > > CloudStack should provide administrator the means to choose the type of > > disk controller (including sub types listed in introduction section > above) for an > > instance. The controller to be used by VM to access virtual disk > (volume) can > > decided for various reasons. Some of them are listed here, > > * Some controllers are optimized for best performance over specific > > backend infrastructure like SAN. Ex: VMware Paravirtual SCSI > > * Compatibility of some controllers with VM's virtual hardware > version or > > guest operating system. > > * Operating system vendor recommendation and default set of drivers > > distributed as part of operating system image. Ex: Windows 8.1 ISO > doesn't > > have Lsi Logic Parallel SCSI drivers by default. Hence a virtual disk > attached to > > this controller won't accessible during installation of OS using the ISO. > > > > CloudStack should provide administrator an option which auto detects the > > recommended disk controller for the instance's guest operating system and > > applicable virtual hardware version. > > Kindly let me know your thoughts. > > > > JIRA ticket - CLOUDSTACK-4787 > > > > Note:- Detailed Functional Specification is to be added at > cwiki.apache.org > > under 4.4 Design documents. Currently cwiki.apache.org is down. Waiting > for > > the site to come up to add the FS document. > > > > Regards, > > Sateesh > >
