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.
Architectural considerations
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:
- Preparation of a CentOS installation ISO which is modified to point to an externally hosted kickstart file. CentOS ISO is stored on a vSphere datastore.
- External kickstart configuration file has to be created to define unattended installation parameters as well as invoke installation of vRA guest agent as last part of the installation. The kickstart file is stored on an external server (e.g. web server)
- vRA guest agent files have to be stored on a network share (e.g. web server)
- Blueprint custom properties have to be defined to e.g. point to the installation sources
Deployment process in high level:
- User requests published blueprint
- Virtual machine is created on vSphere with CentOS iso attached
- VM is booted up and boots from attached ISO
- ISO downloads kickstart file from location defined and runs full unattended installation
- Last part of unattended installation will download guest agent files to virtual machine and install the agent into the virtual machine
- After reboot guest agent is started automatically and reports “success” to vRA
- Process is finished in vRA and VM can be managed in “items” view
Preparation of CentOS ISO
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:
- Provide a web server which is reachable in your network
- Copy the ISO file to the linux system
- Loop mount the iso according to this description: http://bencane.com/2013/06/12/mkisofs-repackaging-a-linux-install-iso/
- In “make your changes” section of above document edit the /var/tmp/linux/isolinux/isolinux.cfg file and add the red append parameters as mentioned below. Replace the <websrv> by the IP address of your web server and adapt the path and file name to your needs. Creation of the kickstart file is described in next section.
| /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 |
- Save the file and create the ISO as per above link’s description
- Copy the ISO to a vSphere datastore e.g. by coping it to a Windows system and uploading it to datastore from there
- Note datastore name (in this case “VM-NFS-01”) and path to ISO file (in this case “/ISO/centos64-unattend.iso”)
Preparation of kickstart file and guest agent
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-CDF6289A2DC8.html
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.
Preparation of the blue print
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.GuestOsDescriptor.GuestOsIdentifier.html
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.
Troubleshooting
ISO checksum wrong
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).
Guest agent trouble shooting
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
- After deployment the guest agent should be installed. You can check this by running “rpm –qa | grep gugent”. This should show a gugent package with the appropriate version number. If the output is empty gugent has not been installed. In this case check the kickstart script for syntax errors in the “rpm –i" command and also check network configuration for DHCP which is leveraged during kickstart installation.
- Guest agent communicates with the vRA IaaS Server in an encrypted way. To do this it has to retrieve the client certificate from the IaaS server and store it in a file. Using the default parameters in above configuration files a file called “cert.pem” should be stored under /usr/share/gugent. If it’s not there or its content is empty check availability of the IaaS server during VM installation and check kickstart file for correct syntax. In addition be aware that during installation the virtual machine uses a DHCP IP address. Make sure that this address incl. the assigned DNS server is able to resolve and reach the vRA IaaS server specified in kickstart file properly.
- Check if vrm-agent is running on the installed virtual machine: “ps aux” should show the appropriate process (VRM_daemon.pl). In addition check if vrm-agent is configured for automatic start with “chkconfig –list” command. If there’s no runlevel entry for vrm-agent but the agent has been installed the kickstart script section with “installgugent.sh” command has failed. This could be the case because cert file is not available or the IaaS server is not reachable.
- For further trouble shooting there’s a log file GuestAgent.log which provides more in-depth information on guest agent issues as well as another log file /usr/share/gugent/axis2/logs/gugent-axis.log which shows even more details.