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.
vSE Implementation 
