vRealize Automation (vRA) provides several methods for provisioning virtual machines from blueprints. These include template based mechanisms as well as workflows leveraging unattended installation procedures to deploy a virtual machine operating system. As some customers do have existing deployment processes they want to leverage a variety of unattended installation methods ranging from SCCM, AutoYaST and RedHat kickstart to name some is supported by vRA.
This blog describes how to leverage kickstart mechanism to deploy a virtual machine in vRealize Automation using CentOS 6.4 x86 as operating system. The process has been tested with vRealize Automation 6.2.3 and version 7.
Be aware this blog is not intended to provide a full step-by-step guide and replace documentation. It furthermore covers the whole process in bullet points and highlights important pieces that are not clearly covered in documentation.
A deployment process in vRealize Automation (vRA) is based on a blueprint which is being cloned when requested by a user. The blueprint itself defines the methodology to be used deploying the virtual machine. In RedHat/CentOS kickstart case there’s a workflow called “LinuxKickstartWorkflow” which is leveraged. Kickstart in a nutshell is the default unattended installation method for RedHat Linux operating systems which is based on a kickstart description file.
Following general steps have to be taken to accomplish the task:
Deployment process in high level:
An existing CentOS ISO (e.g. downloaded from www.centos.org) has to be prepared to include information where to find the kickstart file. There’s multiple ways to modify content of an ISO file, some of them are using commercial tools as most of the freeware tools do have a limit of 300 or 500MB in writing an ISO file. Due to that this document uses a standard linux operating system which provides the functionality for free and also guarantees it works. Follow these steps to modify the ISO:
/var/tmp/linux/isolinux/isolinux.cfg |
---|
label linux menu label ^Install or upgrade an existing system menu default kernel vmlinuz append initrd=initrd.img --bootproto=dhcp ks=http://<websrv>/vra/ks.cfg |
The preparation of the kickstart file is decribed in vRA documentation, see here: http://pubs.vmware.com/vra-62/topic/com.vmware.vra.iaas.virtual.doc/GUID-13EDB88E-DF34-4D82-B17A-CDF...
The file can simply be generated by a text editor. In this case we are using a slightly modified version compared to the documentation which works as well, see here:
ks.cfg |
---|
auth --useshadow --enablemd5 bootloader --append="rhgb quiet" --location=mbr --driveorder=sda zerombr clearpart --all --initlabel text firewall --disabled keyboard us lang en_US logging --level=info network --bootproto=dhcp --device=eth0 --onboot=on reboot rootpw secret selinux --enforcing timezone --isUtc America/New_York install part / --asprimary --fstype="ext3" --size=4096 part swap --asprimary --fstype="swap" --size=512 %packages vim-enhanced %post rpm -i http://<websrvip>/vra/gugent-6.2.2-05062015.i386.rpm export AXIS2C_HOME=axis2 export PYTHONPATH=/usr/share/gugent/site/dops echo | openssl s_client -connect <vra-iaas-srv-fqdn>:443 | sed -ne '/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' > /usr/share/gugent/cert.pem cd /usr/share/gugent ./installgugent.sh <vra-iaas-srv-fqdn>:443 ssl |
Replace all components marked in RED by the paths, IPs, server names tailored to your environment.
After successful modification name the file “ks.cfg” and store it on the appropriate web server path (referenced from isolinux.cfg in modified CentOS ISO file).
Store the guest agent rpm file on the web server as well in the appropriate path.
Create a new blueprint and use the Action “Create” as well as provisioning workflow “LinuxKickstartWorkflow”. Fill all other values according to your needs. In addition there’s some custom properties that have to be set to make kickstart installation work. Find an easy example here:
Image.ISO.Location = Datastore name where CentOS ISO resides
Image.ISO.Name = path and name of CentOS ISO file related to the root of the above mentioned datastore
VMware.VirtualCenter.OperatingSystem = operating system ID of the OS to be installed.
See full reference here: http://pubs.vmware.com/vsphere-55/index.jsp?topic=%2Fcom.vmware.wssdk.apiref.doc%2Fvim.vm.GuestOsDes...
After saving the blueprint, publishing and defining the appropriate entitlements you should be able to request a VM which gets fully provisioned by kickstart process.
If the ISO generation tool does not create proper ISO checksum you will notice this during boot of the virtual machine created. In early boot stage a related message will come up on the console.
If that’s the case use the recommended way to modify the ISO as per this documentation (using linux system).
One important step of the whole process is the successful installation of the guest agent. If this step is not done properly the whole process in vRA will stay in “in progress” status and wait for a time out (which will not occur in less than 24 hours). So it’s essential that the guest agent is installed and starts up properly after reboot to report “success” back to vRA.
Some points to look at