VCO and VCD 5.5 Modify "Instantiate vAPP workflow" with custom virtual machine attributes

[tehkuhnz]

So I have been working on a custom workflow that creates new Instantiations of various vApp templates to dump into our vCloud Director 5.5 env. Overall this a basic clone of of the "Instantiate a vApp template" that comes baked into VCO/VCD plugin.

I am doing a few custom actions at the end (via scriptable task) like changing vApp Owner, change cpu size, memory size, vm name , and computer/guest os name ( all derived from user input). This is all performed after the vapp/vm has been created and I simply power off the vm before making any changes.

All seems to be working fine, except I seem to be running into a bug or an issue where the "computer/guestOS name" is updated within the VCD GUI itself but guest customization failed to update the hostname inside the guest operating system (both Linux and windows based)

A simple power off and “Power On and Force Re-Customization” seems to fix the issue. (I suspect guest customization happens before I power off the deployed vm, and even after my changes are made it is not enough to re-trigger customization when I power the vm back on.)

I started out this search on a more simple effort to see if I can find a method in VCO to just simply replicate a “Power On and Force Re-Customization” and just throw it the end of my post deploy scriptable task. However, I quickly found out that such functionality is extremely hard to find and or does not exist for an existing deployed virtual machine. (PLEASE CORRECT ME IF I AM WRONG!! )

After I gave up on trying to find the elusive re-customization code, I stumbled upon the VCHS/vCloud API guides which reference what I am trying to do, but doing it up front before the vapp is instantiated. These methods reference creating and or modifying sourcedVMInstantiationParams which in theory could modify everything I need and feed into the process before its fired up in the  “createInstantiateVAppTemplateParams” .

I am fiddling around with code to try and feed this process but haven’t had success:

//Source VM HW Params

var coresPerSocketArg =1;

var memorySizeArg = memInputGb;

var numberOfCpusArg = cpuInput;

System.log("Right b4 VclInstantiateVmHardwareCustomizationParams");

//Port them over ??

var hwParams = new VclInstantiateVmHardwareCustomizationParams();

hwParams.coresPerSocket = coresPerSocketArg;

hwParams.memorySize = memorySizeArg;

hwParams.numberOfCpus = numberOfCpusArg;

var sourcedVMParams = new VclSourcedVmInstantiationParams() ;

sourcedVMParams.hardwareCustomization =hwParams;

“sourcedVMParams” is then fed into “createInstantiateVAppTemplateParams” as the variable mapped to the local parameter of  “sourcedVmInstantiationParamsArg”. I have tried many different iterations of this with no success.

This is what I suppose I am trying to recreate within VCO: http://pubs.vmware.com/vcd-55/index.jsp#com.vmware.vcloud.api.doc_55/GUID-DE3617A1-267E-4CD3-914B-83...

But all the references are referring to user the REST API instead of using the vco javascripty language instead. I am very close to just go this route but figure I would post this to see if anyone has any ideas and experience to throw my way.

Any ways – much appreciation for any comments , responses etc.

[Burke-]

Have you considered checking out the workflow I already wrote that has many of the features (and more) that you list here?  Custom Deploy vApp Workflow for vCloud Director 5.1

Also, moderator - please move this thread to the correct Orchestrator community.

[tehkuhnz]

Yes i have looked into your workflow. (Very nice work BTW)

But I am trying to deploy these vApps as fast as possible for user demand with much simpler requirements than provided in your workflow.

If I could bypass the entire post VM customization process by just feeding in my parameters before the Instantiation that would be optimal.

Working on a few things around :

var vmParams = new VclVmParams();

vmParams.needsCustomization = true;

vmParams.name = computerName;

custTask = System.getModule("com.vmware.library.vCloud.operation").reconfigureVM(vm,vmParams);

System.getModule("com.vmware.library.vCloud.common").VclWaitTaskEnd(custTask,pollRateStart,pollRateThreshold);

To see if this would trigger a customization.

[tschoergez]

moved to the Orchestrator forum

[tehkuhnz]

Update on my progress.....

I had a somewhat of an revelation last evening and realized that I may have over-thinking some aspects of my deployment process.

I was literally trying to shrink everything into one script-able task (from the original Instantiate a vApp template workflow so I could play around with modify parameters etc. ) and got to the "createInstantiateVAppTemplateParams" recreation in my task.

I then noticed two key input variables that I have previously ignored..... (deployArg and powerOnArg) while i was manually defining variables for the code below:

.""

.""

var nameArg = vappName;

var powerOnArg = true;  //Wait a minute......:smileyshocked: :smileycry:

System.getModule("com.vmware.library.vCloud.schema.objects").createInstantiateVAppTemplateParams(allEULAsAcceptedArg,deployArg,descriptionArg,instantiationParamsArg,isSourceDeleteArg,linkedCloneArg,nameArg,powerOnArg,sourceArg,sourcedVmInstantiationParamsArg,vAppParentArg);

Short story short, I can run my post scriptable task and modify my VM with all the custom user input, I just need to make sure to set the "Lovely globally defined attributes deployArg, powerOnArg = NO/False".

This way the system doesn't try and power on my vAPP/VM and launch guest customization before I have a chance to modify items like cpus, memeory, disk, and more annoying guest/computername .

And then When I manually power on my vApp all is well in the world regarding computerNames as guest customization fires off properly with all the correct variables.  :smileycool:

___________________________________________________________________________________________________________________________________________________________________________________________

However, If anyone has an answers on   injecting  custom vm parameters before the clone off the vApp please let me know as I trying to make this deploy time as fast as possible. ( Post clone task still works but I would still save a bit of time if I could inject all of my custom parameters in the createInstantiateVAppTemplateParams before the clone rather than after)

And of course if anyone figures out how to “Power On and Force Re-Customization” within VCO that would be also very vital information as that is a useful function to fix vms that tend to go south after user modification etc. Rather than manually having to drill down into the VCD GUI.

[tehkuhnz]

Furthermore, after making my revelation and reviewing Burke's vco workflow... he has the global attributes set to no as well.

"Prevent VM from deploying upon instantiation to allow for other customization first."

If only I saw this comment earlier...