Skip navigation

Although vRealize Operations Manager (vROps) is a great tool for a variety of reasons, one of the more useful abilities it brings to a datacenter is the ability to look inside the guest OS and tell you about its state. Back in 6.2 or maybe 6.3, VMware added the ability to look at guest OS metrics. One of the things they added was guest file system stats on a per-drive basis. The available options as of vROps 6.6.1 look like this.


There is one that displays the usage in percentage, and two that show total capacity and usage in units of GB. What’s absent from this list is a metric that shows remaining disk space in terms of capacity (GB). Curiously, though, this metric was present back in 6.3 but has since been, for whatever odd reason, removed from later releases.


            Now, as far as alerting goes, there is already a preexisting alert in vROps that uses the Guest File System Usage (%) metric to inform you on a per-drive or file system basis when capacity is running low. This alert definition is called “One or more virtual machine guest file systems are running out of disk space” and is based on symptoms of a percentage starting at 85% and going to 95%. And this works perfectly well as you can see from the triggered alert below.


Looks good, right? What’s the problem with that? It’s not a problem per-se, but a limitation on the flexibility of the alerting. Consider this scenario for a moment: You have a number of file server VMs with drives in the multi-terabyte range. Space isn’t consumed on a terribly rapid basis, but you still want to know when you’re running low. If you have a, say, 5 TB drive, using the default alert I showed above at the critical level of 95% capacity still leaves you with over 250 GB free. Probably not deathly critical if you’re not consuming space in a rapid manner. What would be better in these cases is to craft an alert based on arbitrary remaining capacity figures rather than remaining percentage. Unfortunately, vROps no longer has the metric necessary for us to make this happen. Happily, though, we can get this ability back through the use of super metrics. Read on to learn how restore this ability.


            The goal here is to use the super metrics ability in vROps to create a new metric that tells us on a per-drive basis the remaining capacity in GB. Using that new metric, we can create new symptoms, and using those symptoms we can create a new alert. Although this is a mildly-involved process, you fortunately only need to endure it once and never again regardless of how many different drives you might eventually have on systems. In order to carry out these steps, we need a few prerequisites to move forward.


  1. A disposable Windows VM. Can be almost any OS. Best not to use an existing VM that you care about, although these steps should be perfectly safe if you can’t create a new VM from template.
  2. Latest VMware Tools installed on test VM.
  3. vRealize Operations Manager 6.6 or better.
  4. A Windows-based workstation with PowerCLI 6.5.2 installed. Earlier versions should work but have not been tested.


In this tutorial, I have a disposable VM called “space-test” which I’ll use to set this up.



I am providing you with a few resources in this blog to make the process easier including a pre-constructed super metric that needs to be imported, and two Powershell scripts which can be used to add some test drives to your VM and format them inside Windows. Here’s the overall process we’ll follow.


  1. Deploy test Windows VM. Use PowerCLI script to add drives, and use Powershell script inside the guest to format them (both scripts provided).
  2. Import super metric provided here.
  3. Duplicate super metric enough times to cover all possible drive letters.
  4. Activate super metrics in your policy.
  5. Create a symptom definition using these super metrics.
  6. Create an alert using the new symptom definition.


  I’ve already deployed the test Windows VM, so now we need to add drives. The idea with this is to add a drive for every letter in the alphabet that covers all possibilities you might encounter. Since A, B, and C are reserved, and you’ll likely have D as a virtual optical disk drive, we just need the rest of the letters. A simple PowerCLI script I’m providing you does all this in just a couple of lines.


Connect-VIServer -User -Password 'VMware1!'

$vm = Get-VM -Name myvmname

ForEach ($HardDisk in (1..22))


New-HardDisk -VM $vm -CapacityGB 1 -StorageFormat Thin | New-ScsiController




Be sure to edit the script accordingly to connect to your vCenter and provide your VM name. Also, ignore any errors you might warning that the VM must be in a powered off state as they’re false. If this is run successfully, you should have a bunch of 1 GB drives created on your test VM. After that, run the provided PS script inside the guest to bring them online and format them.




$disknum = (Get-Disk | Where partitionstyle -eq 'raw').Number

Foreach ($stuff in $disknum){

Initialize-Disk -Number $stuff -PartitionStyle MBR -PassThru |

New-Partition -AssignDriveLetter -UseMaximumSize |

Format-Volume -FileSystem NTFS -Confirm:$false




Once complete, you should see this madness.



Go into vROps under Administration -> Configuration -> Super Metrics and import the JSON file provided for you.


The result should be this.



Next, duplicate that super metric for as many drive letters as you have (not counting D: if that’s your CD-ROM drive) and change the metric slightly so it references the drive letter. (Unfortunately, I don’t have a script that does this part for you.)


After creating the metrics, add the Virtual Machine as the object type.



Go into your policy and activate these new super metrics. Save the policy.

After a couple collection cycles, you should see these new super metrics working and displaying data on your test VM. You can create a dummy file on a drive that occupies space to see if the super metric is reporting correctly. Something like fsutil file createnew E:\200mb 209715200 will get the job done.


The high value seen above is before the 200 MB file was created, and the low value is after, proving the super metric is collecting accurately.


            Next, we have to create a new symptom definition with these super metrics. Navigate to Alerts -> Alert Settings -> Symptom Definitions. In the metric explorer, change the object type to Virtual Machine. Click the strange button to the right of the “Metrics” drop-down menu and search for then select your test VM. The reason for this (and the whole reason why a test VM was necessary in the first place) is due to a rather unfortunate limitation in vROps to date, and that is you can’t select metrics from which to create a symptom definition just by virtue of them existing in the system. They have to be “active” on an object. If you were to expand the super metrics list there prior to selecting your test VM, you wouldn’t find them. Now that you’ve selected it, however, they appear. Drag-and-drop each of your super metrics into the symptom definition window. Change the definition to suit your needs.



If you expand the Advanced section, you’ll see by default the wait and cancel cycles are set to 3. When complete, save your symptom definition. Once saved, you’ll notice there are individual symptom definitions created for each one. This is intended and rather nice since we don’t have to create them individually ourselves.


We’re almost done. At this point, we have to create a new alert definition that will make use of these symptoms. Walk through the new alert creation wizard giving it a name, description, selecting the base object type of Virtual Machine, setting an alert impact, and then adding symptom definitions. Drag each of them onto the definition so they’re stacked together and not separately. Change the evaluator to be “any” as shown in my example.


This will ensure that you only need a single alert definition to catch any of those symptoms that become true. Once saved, it’s time to test it out. Since I created my symptom definition with the condition that those super metrics need to be less than 5 GB space remaining, I have to increase the size of a drive. After that, fill it up with some test stuff.


Wait a few collection cycles and check to see if the alert fires.



And there we go, we have an active alert on our test system. Since it’s a regular alert, we can do anything we want with it including sending to a CMDB, dispatching an email, generating a web hook, whatever.


            Although this process is, shall we say, uncouth (due to VMware’s redaction efforts), we only have to endure the pain once and all future Windows systems will be covered. But there you have it, we have a good use case for super metrics and have plumbed them all the way through from simple metric to functional alert. Now it’ll be easier for you to integrate this into your process and hopefully keep a closer eye on those drives in the future.


P.S. - The two scripts and JSON for the super metric definition are all available on my GitHub repo here.

Custom Naming in vRA with zero custom coding




Everyone’s got one, everyone needs them, and most people struggle with them. I’m talking about custom machine names, of course. Just like organizations themselves, naming schemes can be, and are about, as varied as possible. Some companies have fairly straightforward names with maybe two elements while others have extremely dynamic requirements that factor in five or six elements. Whatever your naming scheme might be, anyone who has used vRealize Automation (vRA) appreciates the difficulty of getting their naming scheme out of deployed machines. Unless you raised your hand with the more straightforward example and only use a couple simple elements, you aren’t going to be able to get it from vRA out of the box. In vRA, you’re limited to “machine prefixes” which are extremely basic consisting of a name (the prefix), number of digits, and a running counter of what the next number would be. With that, you could do something like “VM001” or “Sales-01” or “vra007”. Although that’s, well, cute, it’s almost totally useless if you hope to integrate vRA into your existing naming standard. To solve this vexatious issue, some have developed ad-hoc packages in vRealize Orchestrator (vRO) that make custom names a little better while others have taken to recreating the wheel themselves, often spending weeks or months writing, testing, debugging, and operationalizing custom code only to find they need to rinse and repeat when the new version of vRA or vRO comes along. So as I hope the picture I’m painting is clear, the solutions to date have not been satisfactory to really operationalize vRA in a stable, consistent, and enterprise-ready fashion. This changed dramatically when SovLabs entered the market with their plug-in for vRA. For the first time, there was a solution that solved many of the difficult extensibility challenges faced by organizations and solved them in a way which was consistent with their existing enterprise software experiences–that is to say, with software that is compiled, tested, maintained, updated, and, most importantly, supported by a team of developers. The solution that we’ll check out here is probably the most popular one amongst the crowd, and that is an enterprise-ready custom naming module. And, as the title of the article implies, we’ll demonstrate how you can implement a complex naming standard into your own vRA with zero custom code.


Custom Naming is just one of the many modules developed and delivered by SovLabs with others including things like Active Directory, DNS, IPAM, Backup-as-a-Service, and all of these from multiple vendors in the ecosystem. Basically, if you want to extend vRA to encompass it, they probably have it. Custom Naming is the one we’ll dive into today, however, but I’ll cover others in the future. This article is really intended to get you familiar with the power of custom naming and how to actually implement it inside vRA. It will assume you have already installed the plug-in in your vRO environment and licensed it appropriately.


Before we begin with the technical bits, we need to come up with a custom naming standard, and one that is realistic to your naming standard. This is what we’ll use as it’s based on a real, live enterprise customer that has datacenters all over the world with thousands of virtual machines deployed.




This needs a little explanation, so have a look at the key below to understand how this is broken down.


L = Location. Datacenter, Continent, Country, or State.

T = Type. P(hysical), V(irtual).

O = OS. L(inux), W(indows), E(SXi).

E = Environment. PRO(duction), DEV(elopment), Q(uality)A(ssurance)T, T(e)ST, ST(a)G(e).

A = Application. Various 3-character codes for any application.

# = Sequence.


Hopefully this is self-explanatory with some of the possibilities next to the descriptor. Based on this name, an example would be LONV-LPROORA023, indicating London, Virtual, Production, Oracle, and number twenty-three in the sequence. This example name is exactly fifteen characters in length, thus able to accommodate Windows’ naming limitations. Also, it’s worth pointing out that the 023 at the end is specific to the combination that precedes it. That is to say that it is the 23rd system that corresponds to that precise name combination, and each different combination has its own set of running sequence numbers.

So, a name like LONV-LPRONGX would have its own separate sequence that is maintained strictly for that combination. As you can see, this six-element name is rather complex yet is very real for some organizations. Let’s go on and see how simple this can actually be to accomplish with SovLabs’ solution.


After getting the plug-in installed and licensed, you’ll see two new catalog items inside vRA. By the way, these are created automatically so you need to do zero work inside vRA to see them. Just so that’s clear, I did not so much as lift a finger here after running a single configuration workflow from inside vRO.

We need to add the sequence first, then when we create the naming standard we will use that sequence as a part of it. Click on the Request button for Add Naming Sequence to pull up the request form.

First, thing is to give it a label. This label will be selected as a component of the naming standard, so give it a name that can easily be tied to that naming standard. I’ll call it “BlogSequence”. Next, select a sequence type. In virtually all of the cases, you’ll want to use decimal, but just in case you have a very unusual sequencing type, you can choose from hex, octal, or even a pattern consisting of a mix of bases and static text. The checkbox to reuse sequence values is for when a machine is destroyed that has a given sequence and you wish to reuse that in a new machine build. Max sequence length, the number of digits involved, three in our example case. Initial value, usually 1. Sequence padding are left-aligned numbers or characters to reach the value, so if your sequence length is three and you start with 1, then setting sequence padding to 0 gives your first machine a sequence of 001. Lastly, the unique key. This requires a bit of an explanation. I talked a bit earlier how we have a specific combination of naming elements that we need to maintain, and I used the examples LONV-LPROORA and LONV-LPRONGX to illustrate this. The unique key is that combination which precedes the sequence number. SovLabs uses a unique template engine to accomplish the work behind the scenes. We need to specify these name elements enclosed in double braces. Type the following below in the unique key window:




“What about the dash? Why do I need to type this stuff, and what does it mean? I’m lost!” Stay with me, all will become clear shortly.


            Go back to the catalog and request the Add Naming Standard catalog item.

Give it a name, choose the naming sequence that we created earlier, and then complete the template. Now, similar to the Unique Key field in the naming sequence, the Template uses the same labels in double braces, only this time we have to format it exactly how we want our name to be formed. So you can see I have added a dash between {{Type}} and {{OS}}. If you refer to our sample naming scheme at the outset, there is a dash that separates those two. So the Template here is the pattern in which the name will actually be generated and slapped on a machine whereas the Unique Key is what the module uses internally to keep track of the number sequences that get assigned. Make sense? Finally, at the end of the template, tack on BlogSequence by adding {{sequence.BlogSequence}}. All sequences must begin with the word “sequence” for the template to be valid. Submit the request and watch it complete.

Once this is successful, let’s see what happened in the background. Navigate t0 Administration -> Property Dictionary -> Property Groups. Notice that a new property group has been created automatically for you once the Naming Standard workflow completed successfully.

The name you see will be prefaced by your tenant, hence the word “ravel” you see above. So now we have a property group ready for use, and we put it to work by simply attaching it to a blueprint. Before we do that, however, we have to put those labels in place from which our naming standard was constructed. After all, vRA has to be able to tell the pieces and parts from which to pull actual names. We do this through the use of custom properties and by assigning them at specific locations inside vRA. Let’s explain.


              If you’re reading this it’s assumed you are familiar with custom properties, but if you aren’t familiar with them know that they’re essentially key/value pairs that enable a rich system of metadata within vRA. Properties can influence the behavior of vRA itself, or be used as tags that are consumed by other things for eventual action. The latter is how the SovLabs module works. Let’s start by taking the first element in our name, {{Location}}. If you have two datacenters into which you can deploy resources, you need to distinguish between the two. You more than likely have a vCenter at each location, and within vRA, vCenter Server is seen as an Endpoint. Find them at Infrastructure -> Endpoints -> Endpoints. Choose your vCenter endpoint and click on the Properties tab. We need to add a new property here with the idea being that if a machine were to be targeted at this endpoint, it would pick up any custom properties associated with it. Likewise, if it went to another endpoint, it would pick up all the properties saved on it. In this manner, vRA does a kind-of “crawl” through the system and whatever constructs were used in forming a machine the related properties are collected into a bundle and delivered to vRO for processing. Create a new custom property and call it Location. In our example naming scheme, location was three characters in length, so give the value of Location as three characters. I’m in Lexington, so I’ll call this value LEX.

If you’ve followed me thus far you’re probably getting the picture here, but just to state it more openly: We need to add custom properties throughout vRA and give them the necessary values which will factor into the custom name.


     To save time, here’s a table that shows the custom property, its value, and where in vRA I created it. This will hopefully give you a good idea as to what’s possible with these properties, but do understand that there are more places than this where properties can be attached.


Custom Property Name

Custom Property Value







Blueprint -> Machine



Blueprint -> Machine



Compute Resource





Ok, so let me show you the blueprint portion since it may not be clear from the table above where those related properties are.


              I created a blueprint called “Oracle” and inside it is a single vSphere machine. There are three of the properties above that I created somewhere in this blueprint. First, the application I created on the blueprint object itself. You access this by editing the blueprint and choosing the gear icon in the upper-left corner.

Three things we have to do here on the blueprint object: 1.) Attach the property group that invokes the modules; 2.) Attach the group which calls our naming scheme; and 3.) Add the Application custom property that contains ORA corresponding to Oracle. When you click the Properties tab, click the Add button and browse for the following property groups.

On the Custom Properties tab now, add a new one and call it Application and provide ORA as the value.

Click OK as we’re done here. Now, click on the vSphere machine you dragged onto the design canvas and go into the Properties tab, Custom Properties sub-tab. Create two additional properties as shown in the table and provide the values.

Make any other changes you need and save the blueprint. Go through the process to publish and entitle it in your catalog. Now let’s go and request it to see if we get the name we want.

And, bam, there it is! So if we request another at this point, it’ll be 002. But if we were to build another blueprint and leave all the same values except change the Application custom property to a something else, say like NGX, the name would be LEXV-LPRONGX001 because this is a different unique key so the sequence is different.


            Now you know the power of what this can do for your custom naming strategy, so feel free to try out various combinations of names, create different blueprints with different machines, and assign custom properties all throughout vRA. Once you become proficient with stringing properties together, have a look at the template language it uses for even more flexibility. For example, maybe you want to re-use the OS custom property in multiple workflows aside from just custom naming, but you need the full word “Linux” and not just a single letter. Using the template engine, the module can perform operations on those property values at runtime, for example you could use the truncate filter to just get the letter L by doing {{OS | truncate: 1}}, and if your naming standard uses lower-case letters you can perform even more manipulation by doing {{OS | truncate: 1 | downcase}}. This would give you the lower-case “l” from the property that has the value “Linux”.


              I hope this article has proven how immensely powerful yet simple and elegant this module is at producing complex names that were impossible otherwise, and all while writing absolutely zero custom code yourself. There’s no need to fear wrapping vRA into your company’s custom naming standard now, because regardless of how complex or involved it may be, the module can handle it with ease.