Supercharging VCF Operations with Custom Management Packs⭐

👋 Before We Start

Do you work with VMware?

Have you used VMware Cloud Foundation Operations or VMware vRealize Operations before?

👉 If yes — great, you’re in the right place.
👉 If not — this might not be the right place for you (yet).

No worries though—I’ll still give you a quick high-level idea so you can follow along.

⚙️ vROps in a Nutshell

VMware vRealize Operations is a monitoring and analytics platform used in VMware environments.

It helps you:

• monitor infrastructure health
• track performance metrics
• detect issues early
• visualize your environment

👉 In simple words: It tells you what is happening inside your VMware environment.

Before we go further, let’s understand this clearly.

👉 A Management Pack is how VMware Cloud Foundation Operations understands external systems.

It defines:

• what to monitor (objects)
• how to collect data (metrics)
• how systems are related
• what to alert on

👉 Without a Management Pack, VCF Operations doesn’t know the system exists.

Now here’s something important to understand.

VCF Operations doesn’t rely only on custom development—it already comes with built-in (out-of-the-box) Management Packs.

👉 For example:

• vCenter integration to monitor your VMware infrastructure

These are ready to use and provide immediate visibility into your VMware environment.

In addition to that, VMware also provides additional Management Packs through the marketplace.

👉 For example:

• VMware Cloud Director (VCD)

These packs are:

• pre-built
• supported by VMware or vendors
• easy to deploy and use

So in many cases, you don’t need to build anything yourself.

⚡ Why Custom Management Packs?

Even with built-in and marketplace Management Packs, not everything is covered.

You may still have:

• custom applications
• few metrics or properties
• internal APIs
• unsupported systems
• or tools specific to your environment

And for these, there is no ready-made Management Pack available.

👉 This is exactly where custom Management Packs come into the picture.

They allow you to:

• bring any external system into VCF Operations
• define your own objects and metrics
• monitor what actually matters to your environment

Remember:
VCF Operations is no longer limited to VMware alone—it becomes your complete monitoring platform.

Taking Control: Building Your Own Integrations

This is where things become powerful.

The VMware VCF Operations Integration SDK provides everything you need to create your own custom Management Pack.

👉 In simple words: It gives you the framework to connect external systems to VCF Operations.

Instead of relying on pre-built integrations, you now:

• define what data to collect
• decide how to collect it
• and control how it is represented in VCF Operations

🧱 Understanding the Building Blocks

When you start working with the SDK, you are essentially building an adapter that connects your system to VMware Cloud Foundation Operations.

This adapter typically handles:

• Data collection → fetching data from external systems
• Data transformation → converting it into the required format
• Data ingestion → sending it into VCF Operations

🏁 Getting Started with the VCF Operations SDK

Now that we understand why we need custom Management Packs and what the SDK provides, let’s see how to actually get started.

Think of this as a roadmap to take an idea → build a Management Pack → deploy it in VCF Operations.

---

1️⃣ Clone the Repository

First, grab the SDK from GitHub:

git clone https://github.com/vmware/vmware-vcf-operations-integration-sdk.git

Inside this repository, you’ll find everything you need to start building a Management Pack.

---

2️⃣ Understand the Folder Structure

Here’s a simplified view of the main folders:

• docs/
  👉 Guides, references, and instructions to help you understand SDK concepts.
• examples/
  👉 Pre-built example Management Packs. Great for learning and testing.
• src/
  👉 The actual code templates where you define objects, metrics, and data collection logic.
• tests/
  👉 Scripts to verify your Management Pack works as expected.
• build/
  👉 Scripts for packaging your Management Pack into a deployable format.

Think of it like a mini factory:

• src/ → you build the pieces
• build/ → you package them
• tests/ → you make sure everything works
• examples/ → you see a ready-made demo

---

3️⃣ Set Up Your Environment (Detailed Step-by-Step)

Before you start building your first Management Pack, you need a proper environment. The SDK has some requirements to make sure your custom packs work correctly.

⚠️ Important: The Management Packs generated by the VCF Operations Integration SDK will only run on versions that support containerized Management Packs. Currently, this is limited to on-prem installs, version 8.10 or later. Also, at least one Cloud Proxy (version 8.10 or later) must be set up in VCF Operations, because containerized Management Packs run on a Cloud Proxy collector.

---

Prerequisites

Here’s what you’ll need:

1. Docker
   • Version 20.10.0 or later (latest stable recommended)
   • For installation instructions, check Docker’s official docs
   • Make sure the Docker default socket is enabled in Settings → Advanced (version 4.18.0 and above)
2. A Container Registry
   • You need write access to push images
   • Repository should be public so Cloud Proxies can pull images anonymously
   • The registry must be accessible by your VCF Operations Cloud Proxies
   • For more info, see the VMware VCF Operations Integration SDK
3. Python 3
   • Version 3.9.0 to 3.12 (latest stable 3.12 recommended)
   • Python 3.13 is not supported, 3.8 and earlier (including Python 2) are not supported
   • For installation instructions, check Python’s official docs
4. pipx (recommended) or pip
   • pipx is preferred to isolate SDK dependencies and avoid conflicts
   • If Python 3 is installed, pip is likely already installed
   • Check pipx installation guide or pip docs -> (For Windows, use py -m pip install –user pipx)
5. Git
   • Version 2.35.0 or later recommended
   • For installation instructions, check Git’s official docs
6. Azul Zulu JDK 17 (Only for Java Adapters)
   • Java Adapters run inside a container, so JDK is not strictly necessary, but recommended for development
   • SDK containers are built with Zulu JDK 17, so using the same version ensures compatibility
   • Get the latest version at Azul Zulu

---

Installation

Once all prerequisites are ready, install the SDK. The recommended way is using pipx to create an isolated environment, which prevents dependency conflicts:

pipx install vmware-aria-operations-integration-sdk

✅ Tip: If you prefer, you can also use pip to install into the global environment or a manually managed virtual environment, but pipx is safer and cleaner..

⚡ Initialize Your First Management Pack Using mp-init

After the SDK is installed, it’s time to create a new project. VMware provides a handy tool for this: mp-init.

This tool will guide you through creating the folder structure, defining metadata, and preparing your first Management Pack. Think of it as your “starter kit” for custom monitoring.

⚠️ Warning: Running mp-init as root (or Administrator) is not recommended, as some directories require standard user permissions to work properly.

---

1️⃣ Run mp-init

Open your terminal (Command Prompt or PowerShell on Windows) and run:

mp-init

This will start an interactive prompt, asking a series of questions to set up your new Management Pack project.

---

2️⃣ Choose Your Project Directory

You’ll first be asked:

Enter a directory to create the project in:

• This is where all your adapter code, metadata, and content will reside
• You can enter an absolute or relative path
• The directory should be empty or not exist yet—mp-init will create it if needed

Example: C:\VCF_SDK\MyCustomPack

---

3️⃣ Set Management Pack Display Name

Next, you’ll provide a display name:

Management Pack display name:

• This is how the pack will appear in VCF Operations: Data Sources → Integrations → Repository
• Default icon is used if none is provided
• Example: TestAdapter

---

4️⃣ Adapter Key

Management Pack adapter key:

• Used internally to identify the Management Pack and Adapter kind
• By default, it’s your display name with special characters and spaces removed
• Example: TestAdapter → key becomes TestAdapter

---

5️⃣ Description & Vendor

Management Pack description:
Management Pack vendor:

• Description: Explains what this pack monitors or does
• Vendor: Appears in the UI under the About popup on the Integration Card
• Example:
  • Description: Monitors custom web applications and APIs
  • Vendor: VMware

---

6️⃣ EULA File

Enter a path to a EULA text file, or leave blank for no EULA:

• VCF Operations requires a EULA
• If you don’t provide one, a stub EULA will be added automatically in the root project directory:

There is no EULA associated with this Management Pack.

You can always replace this later with a proper EULA.

---

7️⃣ Icon File

Enter a path to the Management Pack icon file, or leave blank for no icon:

• The icon shows up in the VCF Operations UI if present
• Must be PNG format, 256×256 pixels
• If no icon is provided, a default icon is used
• You can add an icon later by copying it to the root project directory and updating the pak_icon key in manifest.txt

---

8️⃣ Select Adapter Language

Select a language for the adapter:

• The adapter language determines the initial project structure and some language-specific configurations
• Currently, mp-init offers:

1. Python → Easy to get started, widely used for SDK examples
2. Java → Used if you prefer Java adapters

Tip: For beginners, Python is recommended.

---

🛠️ Debug Tip: If mp-init Fails on Windows

Sometimes, even when you’ve followed all the steps, mp-init might fail — usually with a [WinError 2] during virtual environment creation. Don’t worry! Here’s how to troubleshoot step by step

Check Python, pip, and pipx

Open a Command Prompt and run:

python --version
pip --version
pipx --version

• python --version → Should show something like Python 3.12.7
• pip --version → Shows pip version and location
• pipx --version → Shows pipx version

If any of these commands fail, mp-init cannot create the virtual environment properly.

If you’re following along on Windows, you might run into a situation where pip is not recognized, even though Python is installed. Don’t worry — this happens quite often!

Here’s a simple fix:

1. Check if pip exists inside Python:

python -m ensurepip --default-pip

• This ensures pip is installed for your Python installation.
• If pip is already installed, it will say something like Requirement already satisfied.

2. Verify pip works:

python -m pip --version

• You should see something like:

pip 23.1.2 from C:\Users\Administrator\AppData\Local\Programs\Python\Python312\lib\site-packages\pip (python 3.12)

3. Update the Environment Variables – To make pip globally accessible:

• Copy the script folder path till Python312 and add Scripts at the end like below

C:\Users\Administrator\AppData\Local\Programs\Python\Python312\Scripts\

• Edit the Path value in the environment variables and provide the copied path there.
• Close all terminals (Command Prompt, PowerShell, VS Code), then re-open a new one.

On the safe side, run python --version, pip --version, and pipx --version again to verify everything works.

---

After successful execution, it will displays like this:

🗂️ Base Project Structure: What mp-init Creates

When you run mp-init, it scaffolds a complete project structure for your Management Pack in the folder you specified. Let’s break it down step by step, so you know what each file and folder does.

Here’s the default structure:

.
├── Dockerfile
├── eula.txt
├── manifest.txt
├── requirements.txt
├── venv-<Adapter Name>
├── app
├── conf
│   ├── describeSchema.xsd
│   └── images
│       ├── AdapterKind
│       ├── ResourceKind
│       └── TraversalSpec
├── content
│   ├── alertdefs
│   │   └── alertDefinitionSchema.xsd
│   ├── customgroups
│   ├── dashboards
│   ├── files
│   │   ├── reskndmetric
│   │   ├── solutionconfig
│   │   ├── topowidget
│   │   └── txtwidget
│   ├── policies
│   ├── recommendations
│   ├── reports
│   ├── resources
│   ├── supermetrics
│   ├── symptomdefs
│   └── traversalspecs
│       └── traversalSpecsSchema.xsd
└── resources
    └── resources.properties

---

🔹 File Highlights

• Dockerfile – Instructions to build a container with your adapter code, dependencies, and a simple HTTP server.
• requirements.txt – Lists all Python dependencies needed for your adapter development. (This file does not get copied into the container.)
• eula.txt – End User License Agreement. If you didn’t provide one, mp-init creates a default stub.
• manifest.txt – Top-level JSON file containing information VCF Operations needs to install the Management Pack.

Manifest Key Fields

Property	Description
display_name	The name shown in VCF Operations for the Management Pack.
name	Unique identifier for the Management Pack.
description	Brief description of what this Management Pack does.
version	Version string, e.g., 1.0.1234.
vcops_minimum_version	Minimum VCF Operations version required.
disk_space	Minimum disk space required for installation.
eula_file	File name of your EULA. Defaults to eula.txt.
vendor	Vendor name displayed in the UI.
pak_icon	PNG icon (256×256) to represent your Management Pack.
adapter_kinds	Adapter kind keys included in the pack.

• venv-<Adapter Name> – A dedicated Python virtual environment for this project, so each adapter can use a different SDK version. (Not included in version control.)

✅ Tip: Manifest fields that are “localized” can be set in resources/resources.properties.

---

🔹 Configuration Folder (conf)

Contains configuration files needed by VCF Operations:

• describe.xml – Defines the object model for your adapter and metadata for analysis.
• describeSchema.xsd – Validates your describe.xml.
• images/ – Contains icons for AdapterKind, ResourceKind, and TraversalSpec.

---

🔹 Content Folder (content)

Holds all the “actionable” content your Management Pack can provide:

• Alerts – Alert definitions for objects and metrics.
• Dashboards – Visual dashboards in VCF Operations.
• Reports – Pre-built reports for monitoring insights.
• Policies, Recommendations, Supermetrics, Symptoms – All the management content your pack can deliver.

✅ Tip: You’ll gradually populate these folders as you add real metrics, objects, and relationships to your adapter.

---

🔹 Resources Folder (resources)

Contains localization files, like resources.properties, which map keys in manifest.txt to human-readable names.

---

📂 What is the app Folder?

The app folder is where your actual adapter code lives. Think of it as the “engine” of your Management Pack — everything that collects data, talks to APIs, and feeds metrics into VCF Operations is inside this folder.

Here’s what it typically contains:

• Main adapter script – The Python or Java file that runs when the adapter is invoked.
• Helper modules – Additional Python scripts or classes that help with parsing data, API calls, or calculations.
• Configuration files – Sometimes adapters have small config files for authentication, endpoints, or settings.

---

🔹 Example Structure

app/
├── __init__.py
├── adapter.py
├── collectors.py
└── utils.py

• adapter.py → Main adapter logic, like collecting metrics or discovering resources.
• collectors.py → Functions that fetch data from external systems.
• utils.py → Helper functions (parsing, formatting, logging).
• __init__.py → Marks the folder as a Python package.

Basically, everything your adapter “does” happens here. The rest of the project (content, conf, resources, etc.) is more about telling VCF Operations how to use the adapter, while app is the code that runs.

🎨 Play with the app Folder: Create Your Own Management Pack

Now comes the fun part! The app folder is where all the “magic” happens — this is where you define how your adapter collects data, talks to APIs, and feeds metrics into VCF Operations.

• You can add new Python scripts, helpers, or modules to extend functionality.
• Customize your adapter to fit your environment and monitoring needs.
• Experiment with different objects, metrics, and relationships to see how VCF Operations responds.

💡 Pro Tip: Start small — maybe just collect one simple metric first. Then gradually expand to more complex objects and relationships.

If you need inspiration or references, check out these resources for sample adapters and documentation:

• VMware VCF Operations Integration SDK GitHub
• VMware official Management Pack Developer Guide
• Community examples of custom adapters

Don’t be afraid to play around — this is your sandbox. The more you experiment, the better you’ll understand how vROps sees your environment.

---

Build Management Pack

mp-build

When you execute mp-build, here’s what happens behind the scenes:

• It validates your project — checks that all the necessary files exist (app/, manifest.txt, conf/, requirements.txt) and are correctly structured.
• It builds a Docker container that includes your adapter code, dependencies, and any initialization scripts. This container ensures your adapter runs consistently, isolated from the rest of the system.
• Once the container is ready, it packages everything into a .pak file, which contains the Docker image, metadata (manifest.txt), mapping definitions (describe.xml, traversal specs), dashboards, alerts, and any other content.
• This .pak file is now ready to be uploaded to vROps, where the Cloud Proxy will run the container. The adapter executes inside the container, collects metrics and resources from external systems, and pushes the data into vROps so you can view objects, metrics, dashboards, alerts, and reports.
• Upon the initial use of mp-build in a given project, the tool will request the input of a container registry to push the container image.
• Management Pack is composed of two artifacts: The Pak File, and the adapter image. Both are generated by the mp-build tool, and both are consumed by VCF Operations when installing a Management Pack.

In short: mp-build takes your project → turns it into a container → packages it into a deployable .pak → ready for vROps to consume.

---

What is Cloud Proxy??

Think of the Cloud Proxy as the hands and eyes of VCF Operations. Your vROps instance is the brain — it knows what to monitor, store, and alert on. The Cloud Proxy is what actually goes out, collects the data, and brings it back.

It’s crucial because without it, your custom Management Pack cannot run. Containerized MPs (supported in 8.10+) require a Cloud Proxy to execute. It handles connections to external APIs, databases, and apps, keeps credentials secure inside your network, and distributes workload if you have multiple MPs.

Quick visual analogy:

VCF Operations (Brain)  ←→  Cloud Proxy (Hands & Eyes)  ←→  External Systems

Key takeaway: The Cloud Proxy is your adapter’s gateway to the outside world — if it’s not set up, metrics, objects, and insights simply won’t appear.

Cloud Proxy → Runs the Container(Needs Docker)

• The Cloud Proxy is like the execution engine – hosts and runs these containers.
• Without Docker installed on the Cloud Proxy, the container cannot run, so no metrics are collected.
• It takes the .pak and spins up the container.
• The container runs your adapter code, collects metrics, and transforms them into VCF Operations objects.
• It securely communicates with vROps without exposing credentials outside your network.

Docker → Isolated Execution Environment

• Docker runs your adapter inside an isolated environment.
• All dependencies (Python packages, JDK for Java, libraries) are installed inside the container.
• This ensures:
  • No conflicts with vROps system environment
  • Reproducible results across multiple proxies

Data Flow Back to VCF Operations

• Run reports
• Adapter queries the external system.
• Adapter builds resource objects (VM, server, API, database, etc.).
• Adapter collects metrics for each object.
• Adapter pushes these objects & metrics to vROps via the Cloud Proxy API.
• vROps stores the objects and metrics in the vROps database.
• Now you can:
  • View them in Inventory → Environment
  • Build dashboards and alerts

---

What is Container Registry

When mp-build packages your adapter into a container, that container needs a place to live so the Cloud Proxy can run it. That’s where a container registry comes in.

• Think of it like a warehouse for your container images.
• The Cloud Proxy pulls the container from the registry, spins it up, and starts collecting metrics.
• You need:
  • Write access to push your image
  • Public or accessible registry so the Cloud Proxy can pull it
  • Compatibility with your network/firewalls

Without a container registry, the Cloud Proxy cannot retrieve your container, and your adapter won’t run.

You have many options in market for container registry like VMware Harbour, Azure Container Registry, Docker Hub

---

Visualization Analogy

---

---

Set Up a Cloud Proxy

1. Log in to the vROps UI with an admin account.
2. Navigate to:

Administration → Solutions → Cloud Proxies

3. Click Add Proxy.
4. Provide the following details:
   • Proxy name (e.g., CP-VJ-Auditing)
   • Network/Cluster info where it will run
   • Credentials for the proxy to connect to vROps
5. Verify connectivity:
   • The proxy must be able to reach external systems your adapter will monitor.
   • Test network access and firewall rules if needed.

✅ Tip: One Cloud Proxy is enough for testing, but you can add multiple for load balancing and redundancy.

---

Deploy Your Management Pack

1. Go to:

Administration → Solutions → Add / Install

2. Click Add, then Browse to your .pak file (from mp-build).
3. Click Upload, then Install.

If the .pak includes containerized code, the Cloud Proxy runs the container and executes your adapter.

vROps will automatically assign the MP to your Cloud Proxy.

By default, a collection will run every 5 minutes. The first collection should happen immediately. However, newly-created objects cannot have metrics, properties, and events added to them. After the second collection, approximately five minutes later, the objects’ metrics, properties, and events should appear. These can be checked by navigating to Environment → Object Browser → All Objects and expanding the Adapter and associated object types and object.

---

Configure Adapter Account

1. Navigate to:

Data Sources → Integrations → Repository

2. Locate your adapter (VJ-Auditing-Adapter).
3. Click Add Account and provide:
   • API endpoints
   • Credentials
   • Any environment-specific configuration

Each adapter account can target different systems, so you can have multiple accounts per MP.

---

Final Thoughts

Think of your custom Management Pack like a superhero sidekick for vROps:

🧠 vROps = The Brain
💪 Cloud Proxy = The Arms & Legs
🦸 Your Adapter = The Superpowered Eyes & Ears

Together, they see everything, report everything, and make your environment smarter.

Now go ahead, build your own MP, and let your vROps level up to superhero mode! 🦸‍♂️🚀

🚀 Wrapping Up

And there you have it! From creating your Management Pack project, building it with mp-build, to deploying it via the Cloud Proxy, you now have a fully functional custom adapter running inside vROps.

The key takeaway:

• Your adapter code + mapping definitions feed data into vROps.
• mp-build packages everything into a deployable .pak file.
• The Cloud Proxy runs the container, collects metrics, and sends them securely to vROps.

With this setup, you have the power to monitor virtually any system, extend vROps beyond its default capabilities, and create a custom observability pipeline tailored to your environment.

That’s the magic of custom Management Packs — turning your external systems into first-class citizens inside vROps!

If you have doubts or want to connect, feel free to reach out to me via LinkedIn or email.

If you’re curious but a little hesitant, check out the VMware VCF Operations Integration SDK GitHub — it has plenty of detailed information to explore.

In the next blog, I’ll guide you through coding your own adapter and taking your custom Management Pack to the next level.

Until then, keep experimenting, keep exploring, and keep shining! ✨🚀