Caution: Articles written for technical not grammatical accuracy, If poor grammar offends you proceed with caution ;-)
The Linux Guest agent has not changed much since 5.1. You will notice most everything except the agent version remains basically the same as my article on executing scripts with the 5.1 Linux Guest agent.
Linux Guest Agent
The Linux guest agent has a number of feature benefits that you receive if you utilize it. The Linux guest agent is a small agent that acts very similarly to the vCAC proxy agents. When it is installed you give it the name or IP address of the vCAC server. This allows it to check in with the server when it loads on a newly provisioned machine and determine if there is anything it needs to do. If the vCAC server has work for it to do it send the instructions and the agent executes the instructions on the local guest operating system. The guest agent comes with a number of pre-built scripts and functions, but also allows you to execute your own scripts. Some of the features available with the Linux Guest Agent are:
- Disk Operations – Partition, Format, and mount disk that is added to the machine.
- Execute Scripts – Execute scripts after the machine is provisioned.
- Network Operations – Configure setting for additional network interfaces added to the machine.
This article is primarily about executing scripts with the guest agent, however by installing the guest agent if you add a disk and define the proper paramaters you will be able to utilize the Disk Operations that it supports. I will discuss networking in more details in a different article.
Installing the Guest Agent
1. You will need to install the Linux Guest Agent in your VMware Template that you will be using. In my example I’m using Centos 6.3 x64.
2. You will need to get the agent into your template either by accessing it across the network or by putting it on an ISO and mounting it to the VM. The agent are part of the vCAC installation package and are located under “LinuxGuestAgentPkgs” there you will find agents for a number of flavors of Linux.
3. Once you have your agent on your template you need to install the agent package. There are generally two packages, a tar.gz as well as a RPM. I will be installing the rpm file for rhel6-amd64. The specific package name is “gugent-5.2.3-349.x86_64.rpm”.
4. Install the package by doing the following: rpm -ivh path/gugent-5.2.3-349.x86_64.rpm. In the below image mine was already installed, but you get the idea.
5. Next we need to execute the agent installer. You need to go to /usr/share/gugent and run ./installgugent.sh {FQDNofVCACServer}:443 ssl you can use either the IP address of hostname of the vCAC server.
6. You can verify the proper name/IP by doing “cat rungugent.sh” and looking at the “–host=” statement on the 6th line.
7. If you want to follow the example that I will be giving you should also create a folder on the template to be utilized as a mount point for an NFS share. I created “/Scripts” and my mount point by doing “mkdir /Scripts“.
8. Next I created a helper script in the template that I will use to mount my NFS share. I placed my script in the root of the disk, but you can place it where ever you like. A good place for it would be in “/usr/share/gugent/site/CustomizeOS“, but it really doesn’t matter where you place it.
9. My script is named “repomount.sh” and looks like this: “mount -t nfs $1 /Scripts” nothing fancy at all.
10. Once you have the script created go ahead and “shutdown” your template machine and “Convert it to a template” in “vCenter“.
Configure vCAC
11. If this is a “new template” that you just created you will need to “manually” perform a “Data Collection” in “vCAC“. You can do this by navigating to “Enterprise Administrator” Selecting “Compute Resources” and hover over the cluster that the template exists in and then select “Data Collection” Once there click “Request Now” under “Inventory“.
12. Once the “Data Collection” is complete your “template” will be ready for use.
13. If you don’t already have a blueprint that can deploy this “template” you will need to create one. See my article on “Connecting to vCenter” for instructions on creating a blueprint.
14.Next we are going to create a “Build Profile” that we can use to hold our properties. Navigate to “Enterprise Administrator” and select “Build Profiles” then select “New Build Profile“.
15. Give the “Build Profile” a “Name” and then we are going to add some “Custom Properties” to the profile. We need to add the following properties and values:
- repo.path – This is a property that I made up for this example. It is not part of vCAC. The value should the the path to your “NFS” share in the format “IP:/volume/share” This is what we are going to mount to the folder we created earlier
- VirtualMachine.Admin.UseGuestAgent – This tells vCAC to utilize the guest agent as part of the deployment process. The “value” should be “true“.
- VirtualMachine.Customize.WaitComplete – This tells vCAC to wait until the vCenter Guest Customization is complete. If you do not use “Customization Specifications” you do not need this property. The “value” should be “true” if you use vCenter guest customization.
- VirtualMachine.Software0.Name – Assign a name for the script you are going to execute. “Value” is a “Friendly Name” for your script.
- VirtualMachine.Software0.ScriptPath – Path to your script including the script name. You can pass parameters to your script as well. I’m passing the value for the “repo.path” that I created earlier to my script to be utilizing as the “NFS location” to mount. The value is “/repomount.sh {repo.path}“. Note: The {} brackers are required in the value.
- VirtualMachine.Software1.Name – I’m executing a second script so I’ve used the “VirtualMachine.Software1.Name” property again only with a 1 instead of a 0 this time.
- VirtualMachine.Software1.ScriptPath – I’m executing a second script. This one s located on the NFS share that I am mounting with my first script. My script is “BashScript.sh” and it contains “echo “The script was successfully executed” > /Script_Successfull.txt“
16. Click “Ok” to save the “Build Profile”
17. Next we need to assign this build profile to our “Linux Blueprint“. Go to “Enterprise Administrator” select “Global Blueprints“, then select the “Linux Blueprint” and then “edit“.
18. Once the “Blueprint” opens select the “Properties” tab and select the “Build Profile” you just created and then click “Ok”
So what does all this do
When you request a machine custom properties are associated with the machine. Some custom properties are what we call reserved properties because vCAC understands them and performs actions based on them. The “VirtualMachine.Admin.UseGuestAgent” property tells vCAC that when the machine is provisioning it needs to create workitems for the “Linux Guest Agent” to pick up. The “VirtualMachine.SoftwareX.Name” and “Virtualmachine.SoftewareX.ScriptPath” are put into the work item that is created by vCAC to instruct the ‘Linux Guest Agent” to execute those scripts.
In this example the first script will execute and mount the NFS share that I defined my my own property “repo.path”. Once complete the second script will run and execute “BashScript.sh” which will create a txt file. The guest agent performs it’s tasks after the VMware Guest Customization if being utilized otherwise it completed it after the “Machine Provisioned” state. Once the Linux Agent completed all it’s work items it will then remove itself from loading on future loads and stop it’s service.
I have a few questions regarding this Article. For info, we’re running vCAC Version 5.2.3 Build 349:
1. When provisioning from a Blueprint configured to use the Linux Kickstart workflow method, there appears to be a requirement to import the vCAC Server’s Certificate using the following connection string:
echo | openssl s_client -connect img-tdc-iv02197.gdc.world.ca:443 | sed -ne ‘/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p’ > cert.pem
Is this required when performing a manual execution of the Agent installer? I see no evidence of a “cert.pem” in the /usr/share/gugent directory after installation.
2. The end of your Article states “Once the Linux Agent completed all it’s work items it will then remove itself from loading on future loads and stop it’s service”. The VRM Agent/daemon appears to start up on boot and remain active until manually stopped. In fact, a look at the system’s running processes confirms vrm.pid is actively running. Can you elaborate further or clarify your statement?
Thx Ron.
It is required. I will post a more detailed blog post with more refined steps.
Hi Sid;
One more clarification required.
I discovered a related Article of yours while browsing the site. Although it’s content is virtually the same as above, Step 7 indicated that a bug exists with the Agent. Does this bug still exist in Version 5.2? Is this Step still required? I’ve pasted the info immediately below.
http://dailyhypervisor.com/vcloud-automation-center-vcac-5-1-executing-scripts-with-the-linux-guest-agent/
“…We next need to rename one of the scripts that is included with the Linux Guest Agent due to a bug. Navigate to “/usr/share/gugent/site/CustomizeGuestOS” In this folder you will see a script named “20_static_ip.sh” this script is deprecated and not needed. Rename the script to “old_20_static_ip.sh” by doing “mv 20_static_ip.sh old_20_static_ip.sh“.”
Thx. Ron
Yes you still need to complete it in 5.2
I’ve found that vCAC 5.2 gugent agent causes RHEL 6 VM to crash on firstboot during customization specification.
Life cycle:
1. Request provision of RHEL system through vCAC Self-Service
2. vCenter Clones from existing RHEL template
3. System boots for the first time and performs customization specification.
a. During first boot up vrm-agent is started and begins attempting to contact Dem-Orchestrator
5. Customization Specification finishes, and vCenter triggers OS reboot.
6. System almost completely shuts down, locks up, then kernel panics.
7. Manual intervention to restart power on VM through vCenter reboots system.
8. System boots for second time, staying up, and gugent/vrm-agent completes tasks
With out the manual intervention, the request provision, stuck at that kernel panic times out and the system is destroyed.
I have requested from the same template with out the agent installed and vCAC provisions just fine. We would like to use the agent as there are additional tasks such as registering the system, adding users, and additional security customization of the system.
Has anyone experienced this or know why or how to stop the system reboot after the initial customization specification runs?
I found that if I stick a sleep 60 at the begining of the rungugent.sh, it enables the initial cust spec to finish and reboot the system, except for when 60 seconds wasn’t long enough.
Thanks in advance
Hello Sid,
1. Is it possible to return values from guest agents (Windows or Linux) back to vCAC? If not, how do you suggest that one keeps an eye on the success/failure of the guest customization scripts.
2. What’s the maximum number of scripts that can be attached to a Build Profile through “Virtualmachine.Softeware*.ScriptPath”
You can pass values back to vCAC by making Rest calls to the IaaS server from within your guest scripts. You can also return error codes from within your scripts that get returned to the agent. Although you can’t pass data back to vCAC when doing this you can fail the build if you want. If your deploying to a vSphere environment a better method IMO for running scripts within the guest is to let vCO handle it by executing scripts through the VSphere Guest Agent. Tom Bonanno is working on a package for this but not sure when it will be published. When using vCO you have much better control over what happens when your script fails or is successful.
There is no maximum number of scripts that can be attached to a build profile. I have seen shops that are using hundreds of scripts. The biggest challenge is controlling the order and not having any scripts step on others. Having a solid numbering scheme is key. The other thing to lookout for when having a large number of scripts run on any single build is how long it takes them to run. If they take an excessive amount of time you may need to adjust the timeouts or your build could fail due to the length of time it takes.
Feel free to submit a use case that you are trying to accomplish and we can add it to our list of topics to blog. We are always looking for ideas for what people are looking for.
Sid, thanks for taking the time to respond in detail.
I’ve been reading your posts for the past 2 days and it’s almost criminal how much of helpful information is available on the internet today. I think VMware hit the jackpot by solving their platform’s adaptability, and a professional’s certification or distinction at the same time, with all this openness around their products.
I looked into pyVmomi recently and learnt that it has the ability to run scripts within the guest, but could only return the completion code of the script. vCO, as you say, should be the way to go with all its plug-ins.
Speaking of vCO, I read a post or two right here about packages that do functions around AD in the guest OS.
There’s an (extremely) overwhelming number of blogs in this VMware world; what are the must-read blogs that you would suggest. I’m looking for blogs that not only detail steps, but also ones that are a platform for the author to share their train of thought/intuition when taking on a platform shift (manual work towards automation, for example), and the process of breaking down the objective into smaller steps.
If you scroll down on the right side of the site you will find my blog roll they are great places to start, but as you mentioned there are so many great sites out there it’s hard to narrow the scope. Beyond that google is your friend.