vRA Developer: Part 2 – Dynamically Discover vCAC and vCACCAFE endpoints in vRO

When I work with endpoints in vRO, I like to use actions to discover these instead of hard coding them as attributes or within configuration elements. Hard coding of these endpoints requires manual configuration steps when moving code between environments, which is not ideal. I felt it would be a good idea to include this post early on within this series, as these hosts are often dependencies when working with a lot of my code.

All code that I have provided or talked about in this post can be downloaded as a vRO package for your consumption here.

Discover vRealize Automation Infrastructure (vCAC IaaS) Endpoint

You will generally only have a single vCAC IaaS endpoint in your vRO inventory. I have never worked in an environment where there was more than one. Therefore, the action I have created below requires no inputs and will attempt to discover this single vCAC IaaS endpoint. If you have more than one host for some reason then it should be fairly easy to incorporate this.

Log output:

Continue reading

Upgrading External vRO Appliance to 7.5 (for vRA 7.5)

Oh what a joy of an upgrade this one was. Not that it was too difficult, just a tad annoying that an inline upgrade was not possible (or maybe just not supported?, I dunno) and the only way to upgrade to vRealize Orchestrator 7.5 was through a new deployment of the external appliance and migrating the content and settings across. Anyway, I thought it might be useful to others to document the process that I followed to achieve this (and as a future reminder to myself).

Before you begin

This process documents the steps to upgrade a single, standalone appliance but the steps are almost identical for a cluster. If you are using a cluster, then ensure the load balancer is disabled and that the databases are in sync before proceeding. You are responsible for ensuring that all your appliances, virtual machines, databases, etc are backed up and/or snapshot before attempting to perform the upgrade.

Make sure to also snapshot the target vRO server! If anything goes wrong during the migration, then you will need to revert to this snapshot before you can attempt the migration again. Continue reading

vRA Developer: Part 1 – IaaS & Understanding the Entity Framework

vRealize Automation 7.x is currently in a sort of ‘split brain’ where there exists two data models which can be used to interact with vRA objects. One is objects that are backed by the Cafe appliance / PostgreSQL database and the other which uses the older, entity framework (IaaS servers).

This post is going to focus on the entity framework, which is still very relevant when working with this version of vRA. There are many things that still do not exist in the newer data model, such as custom properties and data collection. I still see vRO/vRA developers struggle with this, so I hope to help improve the situation.

The Entity Framework

When I first worked with vRA, I struggled to understand how objects were stored and manipulated in the database. I often came across a common object class called an entity. I later discovered that all objects stored in the vRA database are considered ‘entities‘. This is because vRA has been developed with Microsoft’s “Entity Framework“. A brief description of this taken from http://www.entityframeworktutorial.net

The Microsoft ADO.NET Entity Framework is an Object/Relational Mapping (ORM) framework that enables developers to work with relational data as domain-specific objects, eliminating the need for most of the data access plumbing code that developers usually need to write. Using the Entity Framework, developers issue queries using LINQ, then retrieve and manipulate data as strongly typed objects. The Entity Framework’s ORM implementation provides services like change tracking, identity resolution, lazy loading, and query translation so that developers can focus on their application-specific business logic rather than the data access fundamentals.

Entity framework is an Object/Relational Mapping (O/RM) framework. It is an enhancement to ADO.NET that gives developers an automated mechanism for accessing & storing the data in the database.

The ‘domain-specific objects‘ reference is key here and are defined as:

Domain objects are represented by entities and value objects that exist within a domain layer. These objects contribute to a common model and are exposed as a data service, which is also provided by the entity framework.

The entity framework is a layer of abstraction that sits on top of the underlying relational database (SQL Server). This abstraction allows developers to work within a standard framework. Yes, you could run SQL queries on the underlying database directly, but this gets really ugly and isn’t supported.

LINQ is Microsoft’s .NET Language-Integrated Query (language).

What is also important to note is that entities follow some form of continuity and identity (i.e. they must all have certain attributes, such as an ID field or callable methods). This standard allows for a consistent interaction with the domain objects.

In the case of vRA, all domain-level objects (entities) are provided under the ‘ManagementModelEntities.svc‘ data service model. Within this data service model, entities are organised into their own ‘tables’, known as ‘Entity Sets’, and entities can also link to (relate to) other entities. Getting an understanding of the entities will make your life as a vRA/vRO developer so much easier. Continue reading

vRealize Orchestrator: Standardised Logger Action


I have updated this page on 22nd Jan 2019 to introduce enhancements over the original logging action. I have converted the original function calls to an object based approach. This allows a logger object to be used, which looks cleaner and is initialised once. I have also introduced JSDoc documentation styles into my code.


One bugbear that I have with vRO is the limitation around system (console) logging. There is currently no way to dynamically output the name of an action or sub-workflow (see end of the post). I like to see exactly which action or workflow is executing code. This makes it easier for me to troubleshoot a defect, when I am looking at the output logs.

It is possible to use ‘workflow.name’ or ‘this.name’ inside an action, but this will always be set to the name of the initial workflow that was executed. This is because the workflow object is implicitly passed to the action that is called. The result, is that it will look like all the code is executing from the workflow (which is technically true, but I needed more granularity).

I therefore created a standardised way that workflow and action logging should be handled. This is achieved by using an action that will actually handle all the logging for me. The idea is, that an action or workflow will call the ‘logger‘ action, providing some parameters, that allow for a consistent and useful logging experience. Continue reading

vRealize Orchestrator: Standardising Modules & Actions


I have updated this page on 22nd Jan 2019 to introduce improvements over the original Action template and module structure. I have introduced the new logger object and JSDoc documentation styles into my code.


Managing your code base in vRealize Orchestrator can be quite challenging and complex. Often, you won’t realise this until you’ve reached a point where it becomes difficult and time consuming to both organise or locate existing code that you have written. In this post, I am going to suggest ways to help you organise your code better, using methods that I have adopted with my time using vRO.

I am not suggesting this be the perfect solution, but it should provide a working standard to adopt to your own needs. I would also argue that the extra time spent getting this in place on the outset, will lead to time saved later on.

Just for reference, from this point on, I am going to refer to ‘code base‘ and ‘actions‘ interchangeably, because your vRO actions ARE your code base. Almost every single line of code you write in vRO should be in an action (I will discuss this in more detail in a later post which I will link here).

Actions

Here are some general principles I like to follow when creating actions: As a general rule, actions should:

  • Contain small, manageable chunks of code that perform a specific task. Actions are just functions and just like any function, it should contain code that performs a specific task. If your action is doing many different tasks, then consider breaking these down into multiple, smaller actions.
  • Validate inputs. I appreciate that some may debate this idea, but actions are not ‘private functions’. They are public code where you can never guarantee that the action ‘caller’ is properly validating its inputs. This is the nature of vRO, it is a ‘hub’ that has many different uses cases and scenarios for executing the same actions. I have seen dozens of cases where developers and support engineers have wasted time tracking unexpected errors;
  • Be named appropriate to the task they perform. I generally like to use verbs in my action names, like, ‘getVirtualMachineNames’, ‘getVirtualMachineNetworks’ or ‘setCustomProperty’. Actions named this way will make it easier for other developers to identify what they are used for;
  • Have variables declared in a single block. This will just make it easier to see what variables are being used. The data type can also be defined, but is not always necessary or as important;
  • Provide consistent logging throughout. Make it so, the action almost tells the story of what is happening. Don’t go overboard, but generally a before, during and after style to logging works quite well;
  • Nesting actions within an action is generally ‘OK’ but keep it to a minimum if possible. Too many nested actions can create depth that may be more difficult to maintain and troubleshoot later on. Typical use cases are ‘helper’ or ‘utility’ actions (you’ll be completely forgiven with actions used for workflow presentation as these are a pain);
  • Perform singular tasks. Don’t write actions that perform plural tasks. Write the singular version first, then use a looping mechanism that re-uses the singular action (there are also ways this can be achieved with performance in mind in vRO). This way you’ll only have 1 version of the code;
  • Be based on a user-defined template. Yup, I’m not crazy. Have a defined template (aka boilerplate) set out on how an action should generally look and have the team follow this. It will make code reviews far easier;
  • Always use camel cased alphabetical characters (no dots);

Continue reading

Install phpVirtualBox on CentOS 7.x

I have to say, I have been bursting with some excitement to recently discover this gem. phpVirtualBox is going to make a great addition to my server by allowing me to create and manage VirtualBox VM’s direct from my web browser. So just a small guide, sticking with the theme, on getting phpVirtualBox installed and running on CentOS 7.x.

Install required packages

Install Apache Web Server

Start Apache and ensure it starts automatically on boot.

Finally, add an exception in the firewall so that you can access Apache over HTTP and HTTPS.

Test that Apache is running and accessible by opening a browser and navigating to http://server_ip_address.

Install PHP

Restart Apache.

Test that PHP is working by creating a PHP test file that will display the PHP information page (watch out for the quotes if copy/pasting).

Verify that the PHP information page loads by opening a browser and navigating to http://server_ip_address/test.php. Continue reading

Importing Existing VMs/OVA’s Into VirtualBox

Before I decided to run a Linux based, headless installation of VirtualBox, I had been running all my virtual machines in VMware Workstation. When it was time to switch I exported a number of virtual machines that I had already built to OVF format. These were servers like Windows with Active Directory, GIT, Ansible, that I didn’t want to go through the hassle of building again from scratch. This post is dedicated to my experience of doing this and some of the post migration work that needs to be performed, such as removing VMware Tools, etc.

Import Existing Virtual Machine Image

Before you get started

One tip before you start. When you import the VM into VirtualBox, it’s possible that the network adaptor information will change. This was definitely the case for me when I migrated from Workstation that used the VMXNET3 driver. My interface was configured as ‘ens33‘ and when I switched to the virtio driver in VirtualBox the device came up as eth0. I was therefore unable to connect to my headless VM. My solution was to fire up the source VM again and copy the ‘ifcfg-ens33‘ in /etc/sysconfig/network-scripts/ to ‘ifcfg-eth0‘ and change any references from ens33 to eth0. Finally, I commented out the UUID line. When I re-imported, I was able to connect the my VM.

Import Virtual Machine

To perform the import I am going to use the VBoxManage import command. This command allows the –dry-run flag to be supplied and will provide details of how the virtual machine will look once it has been imported into VirtualBox. This is useful as it allows us to ensure that the configuration is how we want it to be. The dry run will also provide any optional flags that can be used to influence the import. There are also the global options keepallmacs, keepnatmacs, and importtovdi.

I have some virtual machines that have been exported to OVF format:

So let’s take a look at my Ansible (SG1-ANS001) virtual machine that is running on CentOS 7.x.

The dry run feature represents the virtual machine image as a Virtual system followed by an index. As this image only contains a single virtual machine, only index 0 is present. The VM hardware configuration is listed as units. Therefore, I can go through each unit in turn and ensure that the target machine is configured correctly. From the dry run output there are a number of units that need to be modified. I will build out the command as I go along.

1: Suggested VM name “vm” (change with “–vsys 0 –vmname <name>”)

This will need to be changed to the actual name of the VM, which in this case is SG1-ANS001. I can use the options –vsys 0 –vmname <name> to accomplish this.

5: Network adapter: orig custom, config 5, extra type=Bridged

The original VM was using a custom host-only network interface on the previous hypervisor which is not understood by VirtualBox. The import command is therefore defaulting to a suggestion of a Bridged interface, which is not correct. I need connect the virtual network card to my vboxnet0 host-only interface on VirtualBox. Unfortunately, the import command does not provide an option that I can see which can make this change. I will therefore need to modify the VM once it has been imported.

9: Hard disk image: source image=SG1-ANS001-disk1.vmdk, target path=/mnt/vm2/vbox/vm/vm/SG1-ANS001-disk1.vmdk, controller=7;channel=0

The source disk image is a VMDK, the format used by VMware. Although VirtualBox uses the VDI disk image format, it has defaulted to continue using VMDK. This will still work but as my goal is to move to a fully Open Source solution, converting to VDI makes more sense. The global option importtovdi can be used to achieve this. My command now looks like:

VirtualBox will default to re-initialising the MAC address of all network cards on the VM. I am not interesting in making post configuration changes because of this and my preference would be to preserve the existing MAC addresses that was allocated to the original VM. There is no real reason not to do this. The global option keepallmacs can be used to achieve this. My final command now looks like this:

If we issue another –dry-run against the new command we can see most of the changes have taken effect.

We can now re-issue the command with the –dry-run omitted to perform the import of this virtual machine into VirtualBox. The progress will be displayed and a message if the import was successful:

Post-Import Configuration

Let’s check that we can see the VM in the VirtualBox inventory:

Configure Networking

If you recall from the previous section, we were not able to change the network card binding during the import. We can do this now that the VM has been imported using the VBoxManage modifyvm command. I need to bind to a host-only interface called vboxnet0.

I also want to use the paravirtualized Network Adaptor using the virtio driver for better performance.

The VBoxManage showvminfo command can be used to view the VMs configuration, which can be used to confirm any changes that have been made.

Disable Audio

I noticed from my VBoxManage showvminfo output that an Audio card was enabled.

Audio: enabled (Driver: ALSA, Controller: AC97, Codec: STAC9700)

I do not require this so the card can be disabled:

Set VM Description

While we’re at it, it would probably be a good idea to give this VM a small description.

Virtual Machine Power Operations

Start VM

Since we’re going to be running this VM in headless mode, the alternative binary VBoxHeadless will be used instead of VBoxManage. The VBoxHeadless interface accepts the same start parameters. If you see the copyright information after you have run the command then the VM will have been started successfully.

Use the  VBoxManage list runningvms command to verify that the VM process is actually running.

Stop VM

You can gracefully stop the running VM using the VBoxManage controlvm <vm> acpipowerbutton command.

Troubleshooting

If you aren’t able to connect to the VM after it has been started then it may have failed to boot or a network configuration issue. As the VMs are running in headless mode it can be difficult to diagnose. There are a couple of decent ways to help diagnose the issue.

Screenshot

This option is simple and takes a screenshot of the console. You can specify the filename to save (in PNG format) then download this via SCP from the VirtualBox host.

Serial Port (console redirect)

I will follow up with an additional post on how the display output can be redirected to the serial port and some cool ways that we can view and interact with this session.

If there is some other configuration that I could apply to my VMs or vbox installation, then please let me know.

CentOS running VirtualBox (headless mode)

Today I started work on something that has peeked my interest for a while, switching my server to CentOS running VirtualBox in headless mode.

I had long been a fan of VMware Workstation, back in the day, it was more feature rich than Vbox and provided better memory management features. Alas, that is not the case today and with VirtualBox’s powerful ‘VBoxManage‘ CLI, it really fits in well where I can write all my infrastructure in code (and yes, I’ll most likely layer Vagrant on top of this). VirtualBox also provides an alternative headless interface ‘VBoxHeadless‘, which means there is no requirement to run a GUI on my server.

As I am starting out on this new journey I felt that it would be great to blog about and hopefully help others that want to do this.

All I have from the start is a minimal installation of CentOS 7.4 (Core). I am using the following as a guide for the VirtualBox installation: https://wiki.centos.org/HowTos/Virtualization/VirtualBox.

VirtualBox Installation

Install Dependencies

Install Extra Packages for Enterprise Linux (EPEL)

Install Dynamic Kernel Module Support (DKMS)

This will install quite a few packages:

Install Development Tools

I want my server to have access to a basic development environment so we’ll install the group packages for this. This will install packages such as gcc, make, binutils, etc. Use ‘yum groupinfo “Development Tools“‘ to view the entire list of packages installed in this group.

Install Kernel Development

Install VirtualBox

Add the VirtualBox package repository

Install VirtualBox

This will also install a number of dependencies.

Install VirtualBox Extension Pack

The VirtualBox Extension Pack will add support for the following:

  • USB 2.0 and USB 3.0 Host Controller
  • Host Webcam
  • VirtualBox RDP
  • PXE ROM
  • Disk Encryption
  • NVMe

Download the extension pack:

Once downloaded, install the extension pack:

OR, if you are upgrading from a previous version of the extension pack, then you will need to add the ‘–replace’ option to uninstall the old version first.

Agree to the license terms and conditions.

The extension will be installed.

Verify that the extension pack has been installed successfully.

You should see output like the following:

Add Users to ‘vboxusers’ Group

When VirtualBox is installed a new group ‘vboxusers’ is created. Users that are a member of this group will be allowed to run VirtualBox. I will add my non-privileged user to this group.

Verify Installation

VirtualBox Linux kernel module (vboxdrv)

Check that the vboxdrv service has installed correctly and is running.

You should see output like the following:

The status should be ‘loaded‘ and ‘active‘. If you see a ‘Kernel driver not installed‘ message then try running the following command:

VirtualBox Web Service (vboxweb)

Check that the vboxweb service is running:

You should see output like the following:

Configure VirtualBox

Configure Networking

I have some basic network requirements for my lab to start out with. I will use a host-only interface, which will be the management network and a NAT interface, which can be useful for VMs that I want to access the Internet without going through the virtual firewall. I will also need to bridge one of my virtual firewall’s network interfaces to the servers physical interface (so that I can do some additional routing on my physical network).

I can see what network interfaces are currently available using nmcli.

Create the Host-Only Interface

We can confirm that the Host-Only interface was successfully created using nmcli.

Assign Network to Host-Only Interface

To confirm that the IP address has been assigned, use the ip command.

Create NAT Interface

I want to create a NAT network on 192.168.15.0/24 and have IP addresses allocated to clients automatically using DHCP.

To confirm that the NAT network has been created use the following command.

We can see that the network has been created and an IP address has been allocated automatically for the gateway (uses the first available address). This should be enough to provide outbound Internet access to any VM NICs attached to this interface.

Global Settings

I also like to configure some global settings so that I do not need to keep specifying these when creating new virtual machines.

Default Virtual Machine Folder

I actually have 2 large SSDs that I spread the VMs across for IO reasons. I will default to one of these and manually specificity my second disk when required.

Exclusive Hardware Virtualization

VirtualBox will be given exclusive use of the hardware virtualization extensions (Intel VT-x or AMD-V). I think this defaults to on but let’s set it anyway.

Default Front End

I am not running a GUI on this server so all virtual machines will be running in headless mode.

That concludes my initial setup and now I am ready to start deploying my virtual machines. I will provide posts on my new virtual machine deployments as I build out my new infrastructure using VirtualBox. I also have a number of OVF’s that I exported from my old environment that I’ll be importing and will document the steps along the way.