To set it on the template, simply edit the template once it's created: cmk update template id=xxxxxx details[0].rootDiskController=pvscsi details[0].keyboard=uk details[0].nicAdapter=Vmxnet3
I have not tried to create a template with the "details" - feel free to use the same command structure as in the above example - per the API docs, it should work. Best, Andrija On Fri, 17 May 2019 at 13:48, Riepl, Gregor (SWISS TXT) < gregor.ri...@swisstxt.ch> wrote: > Thanks, the manual change in ESX is basically what we did when changing > the details in CS didn't have the desired effect. > > > Can you clarify how to correctly set the root disk controller for a > template? With the rootDiskController detail, as we tried to do it for VMs? > > > Since we'll be relying more on cloudmonkey from now on, what would be the > corresponding command line to this? > > > $ cmk create template details=.... ? > > > I have a vague recollection that cloudmonkey had an issue with nested data > structures specified as arguments. > > Is this still the case? > > ________________________________ > From: Andrija Panic <andrija.pa...@gmail.com> > Sent: 17 May 2019 11:45:40 > To: users > Subject: Re: Changing the NIC and disk controller type permanently > > Gregor, > > I already shared the solution for existing VMs - for any new VMs to be > deployed from some template, please change the template details and specify > the rootController type as you need it - this will make sure all new VMs > deployed from that template will inherit the specific root controller > type... > > Let me know if that works for you. > > Andrija > > > On Fri, 17 May 2019 at 15:07, Riepl, Gregor (SWISS TXT) < > gregor.ri...@swisstxt.ch> wrote: > > > Hi Andrija, > > > > > > Thanks for the update, I kind of feared that this still wasn't possible > in > > a clean way. > > > > > > As evidenced by the results, setting the details via the commands I > posted > > *did* have a certain effect, it just didn't work correctly for the root > > disk controller. > > > > > > I know that changing the controller can make Windows unbootable, but for > > us, it was the opposite: Having the controller set to the default > lsilogic > > (not SAS) would result in unbootable Windows VMs, because the LSI Logic > > Parallel SCSI drivers were removed in Windows Server 2012. Without > > injecting them into the Template, new VMs deployed with this controller > > won't boot. Since we had a hard time preparing such a template, our > > solution was to modify the controller instead. > > > > > > That's why I'm asking how to change this permantenly, so we won't have > the > > issue with Windows VMs any more. > > > > > > The same applies to the NIC. The Windows E1000 driver is unreliable with > > VMware's emulation, so we'd like to switch to VMXNET3 for all Windows > VMs. > > Setting the nicAdapter detail worked as expected, at least. > > > > > > Any suggestions? > > > > > > Regards, > > > > Gregor > > > > ________________________________ > > From: Andrija Panic <andrija.pa...@gmail.com> > > Sent: 17 May 2019 08:30:22 > > To: users > > Subject: Re: Changing the NIC and disk controller type permanently > > > > Hi Gregor, > > > > the code around managing VM details for existing VMs (CONTROLLER > > specifically) could be a bit better - but in short - there is NO way to > > change existing controller type from the current ones (for VMware > > specifically) using CloudStack (btw you "can" make the change in the GUI, > > while VM is stopped - there is a "Settings" tab there.) > > > > You "can" change these details on the VM level (existing VMs) via > API/GUI, > > this changes the records in the "user_vm_details" table - but simply > these > > new values are NOT read/applied during starting an existing VM - > actually, > > even when you change that in GUI (or DB) and start a VM - these values > will > > be reverted back. > > > > I just did more tests - and the way to change it would be to stop VM, go > to > > vCenter, change (all 4 controllers) to " LSI Logic SAS" (or any other > you > > want) - then go back to CloudStack and edit VM details (Settings tab, > while > > VM is stopped) to "lsisas1068" - simply to sync ACS to reality (to > > vCenter). > > > > Make sure to do proper testing, since changing root controller driver in > > Windows can sometimes cause it to fail boot. > > > > Best, > > Andrija > > > > > > > > On Thu, 16 May 2019 at 21:44, Riepl, Gregor (SWISS TXT) < > > gregor.ri...@swisstxt.ch> wrote: > > > > > > > > > $ cloudstack addResourceDetail "details[0].key=rootDiskController" > > > > "details[0].value=lsisas1068" "resourcetype=UserVm" "resourceid=$id" > > > > > > Note: lsisas1068 comes from > > > > > > > > > https://github.com/apache/cloudstack/blob/4.11.2.0/vmware-base/src/com/cloud/hypervisor/vmware/mo/ScsiDiskControllerType.java > > > > > > We had set this to lsilogicsas previously (on CS 4.5), which causes the > > > following exception on start on CS 4.11.2.0: > > > > > > com.cloud.utils.exception.CloudRuntimeException: Invalid root disk > > > controller detected : none > > > at > > > com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResou > > > rce.java:1690) > > > at > > > com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(Vmwa > > > reResource.java:496) > > > at > > > com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgen > > > tAttache.java:315) > > > at > > > org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(Mana > > > gedContextRunnable.java:49) > > > > > > ... > > > > > > > > > -- > > > > Andrija Panić > > > > > -- > > Andrija Panić > -- Andrija Panić
