Sunday, 6 January 2013

vCenter Orchestrator WorkFlows - Example

The purpose of the this workflow is to automatically deploy new Virtual Private Server (VPS) which is directly connected to external network. This is a typical requirement for public cloud. 

The end user is supposed to enter the following inputs while deploying the VPS:

1. VPS Name 
2. Computer Name 
3. VPS Favorite OS 
4. Number of CPUs 
5. Total CPU capacity 
6. Memory capacity 
7. Disk Space

The workflow shouldn't run in case any of those inputs is null to avoid misbehaving of vCD environment (I am not going to cover this part as I have already explained it in my previous post in Presentation section).
The workflow will operate as follow:

1. Create Organization named using the VPS name. Other OvDC parameters (vCD server, vAPP storage lease, etc) are hardcoded using attributes in the workflow.

Note: Make sure to set the value of InvalidLoginsBeforeLockout. Although this isn't a mandatory parameter during manual Org creation, workflow will fail if this parameter isn't set in Add an Organization workflow element.

2. The storage capacity of OvDC should be more than VM storage capacity to accommodate swap file, media (future use), catalogs (future use), snapshots, etc. Here we are adding 20 GB extra  to the OvDC capacity above the amount of disk space enter by the end user using scriptable task.

OrgDiskSize = RequiredSize+20000; 
3. Create OvDC and assign it to Organization as resource provider. Some OvDC parameters are hardcoded using attributes such as PvDC, VMs quote, thin/fast provisioning, etc while others are obtained  from user inputs such as CPU Quote, Memory Quote, storage quote, etc. Note: Storage Quote is increased by 20GB above the amount of storage entered by end user.

4. Create OvDC Network to provide connectivity to vAPPs in Org. Here we are using direct network connected to vDS port group.

TIP: This port group is configured with isolated pvlan to avoid direct communication between VPS's at L2 level (similar to vCNI concept but at simpler level). Communication between VPS's should cross the hosts going to L3 device which is responsible for routing between them. This L3 devices can use ACLs to maintain security.

5. Clone a VM from vAPP Template. The flavor of the VM will  be selected by end user such as RHEL-6.2-x64, win2008-R2-x64, etc. Make sure that you disable the following in your visual binding:

a. Deploy vAPP - This will fail the workflow since vAPP network not yet created. Its needs to be disabled till vAPP network is created, then we can deploy the vAPP.
b. Power-On - Since the vAPP isn't deployed yet and vAPP network is not created, this will fail the workflow. We can move it as last step.
c. Delete Source

6. After this you need to get the VM created inside the vAPP in order to set its customization section. vCO has an action to get all VMs in vAPP which will result with an array. Therefore, you need to use scriptable task to get one VM from the array and customize it.

var VmNumber = GetAllTheVmsInTheVapp.length;
VmNumber = VmNumber-1;
VmName = GetAllTheVmsInTheVapp[VmNumber];

var guestCustomizationSection = System.getModule("com.vmware.library.vCloud.operation").getGuestCustomizationSectionVM(VmName) ;
guestCustomizationSection.computerName = ComputerName;
guestCustomizationSection.changeSid = true;
guestCustomizationSection.resetPasswordRequired = false;
guestCustomizationSection.adminPasswordEnabled = true;
guestCustomizationSection.adminPasswordAuto = false;
guestCustomizationSection.adminPassword = DefaultPassword;
guestCustomizationSection.joinDomainEnabled = false;
task = VmName.updateSection(guestCustomizationSection);

7. Next will be creating vApp network. We have used direct network again to have VM connected directly to OvDC network which is in turn connected directly to external network. We also introduced 3 sec delay between customization step and vApp network creation. This is required to have the VM in ready state before creating vApp network.

8. Once vApp network is created, we need to connect the VM to vApp network to get an IP address (either from pool, DHCP, or manual) as well as MAC address.
9. The workflow will change the number of vCPUs and memory size based on user input. The memory size is the same as OvDC memory quote which is entered by user. 
10. The next step will be changing the amount of disk space of the VM based on user input. Here we have two options:

a. Change the disk space of OS partition of the VM. This requires user intervention to expand the disk space manually from the guest OS (e.g. in win2008 you need to use disk management)
b. Keep the OS partition size of the VM based on your template and create new hard disk based on user input. No user intervention is required. Once the VM boots two hard disks will be detected by OS and ready for use.

I selected the first method since it needs more steps which I would like to show, however, from productivity point of view I prefer the second method.

Note: The size entered by user won't be increased at VM level similar what we did at OvDC level.

11. We need to list all disks in the VM which will provide an array of disks names. From this list we will pick the OS disk using scriptable task and change its size.
var NumberOfHardDisks = ListVmHardDisks.length;
NumberOfHardDisks = NumberOfHardDisks-1;
OsDisk = ListVmHardDisks[NumberOfHardDisks];

12. At last, we will deploy the vApp since all required parameters are adjusted and ready for use. The VM is ready to run.

Here is the workflow file attached.

No comments:

Post a Comment