Tag: VCF

VCF Orchestrator Node.js Environment Variables

In this blog post, we will explore how to use environment variables in a Node.js script running inside Broadcom VMware VCF Orchestrator. Environment variables are a great way to configure your scripts without hardcoding values, making your code more flexible and secure.

Environment Variables in VCF Orchestrator

For this example, we will use two environment variables available in the VCF Orchestrator environment.
– KAFKAJS_NO_PARTITIONER_WARNING
– NODE_TLS_REJECT_UNAUTHORIZED

These variables are commonly used when integrating with Kafka or handling TLS certificates in Node.js.

01 - VCF Orchestrator - Node.JS - Environment variables
VCF Orchestrator – Node.JS – Environment variables
02 - VCF Orchestrator - Node.JS - Setting environment variables
VCF Orchestrator – Node.JS – Setting environment variables

Loading and Validating Environment Variables

Below is a function that retrieves these environment variables and validates their values:

// Load container environment variables
const loadEnvs = () => {
    const { KAFKAJS_NO_PARTITIONER_WARNING, NODE_TLS_REJECT_UNAUTHORIZED } = process.env;

    // Validation: only "0" or "1" are allowed
    if (!['0', '1'].includes(KAFKAJS_NO_PARTITIONER_WARNING)) {
        throw new Error(`${LOG_PREFIX} Invalid KAFKAJS_NO_PARTITIONER_WARNING value: ${KAFKAJS_NO_PARTITIONER_WARNING}`);
    }
    if (!['0', '1'].includes(NODE_TLS_REJECT_UNAUTHORIZED)) {
        throw new Error(`${LOG_PREFIX} Invalid NODE_TLS_REJECT_UNAUTHORIZED value: ${NODE_TLS_REJECT_UNAUTHORIZED}`);
    }

    // Return the validated variables
    return { KAFKAJS_NO_PARTITIONER_WARNING, NODE_TLS_REJECT_UNAUTHORIZED };
};

Explanation: We destructure the variables directly from process.env. Validation ensures the variables are either “0” or “1” only, preventing invalid configurations. The function returns an object with the validated variables, which can be safely used in your script.

Using the Environment Variables

Once loaded, you can use these variables in your Node.js script like this:

// Load environment variables
const envs = loadEnvs();

console.log(`${LOG_PREFIX} Setting environment variable KAFKAJS_NO_PARTITIONER_WARNING=${envs.KAFKAJS_NO_PARTITIONER_WARNING}`);
console.log(`${LOG_PREFIX} Setting environment variable NODE_TLS_REJECT_UNAUTHORIZED=${envs.NODE_TLS_REJECT_UNAUTHORIZED}`);

This allows you to reference the environment variables throughout your script, for example to configure KafkaJS behavior or TLS certificate validation.

Why This Approach Is Useful

  • Centralized configuration: No hardcoding; variables can be changed per environment.
  • Fail-fast validation: The script throws an error immediately if a variable has an invalid value.
  • Secure defaults: Particularly important for TLS and security-related flags.
  • Reproducibility: Works consistently across VCF Orchestrator containers.

This setup ensures that your Node.js scripts in VCF Orchestrator are flexible, secure, and maintainable, while keeping the environment-specific configuration outside your code.

VCF Orchestrator the JavaScript week-number

While working with Broadcom VMware Cloud Foundation (VCF) Orchestrator, formerly known as vRealize Orchestrator, I ran into a subtle but very real problem: week numbers that did not match what we expect in The Netherlands.

At first glance this looked like a bug in the platform. In reality, it turned out to be a classic JavaScript date-handling pitfall that becomes especially visible in automation workflows.

The issue: week numbers don’t line up

In one of my Orchestrator workflows I evaluated two timestamps:

  • 2025-02-17 20:39:00.000 +01:00 → returns week 7
  • 2025-02-18 20:39:00.000 +01:00 → returns week 8

From a Dutch perspective, both dates fall in week 8. So why does JavaScript suddenly jump a week overnight?

ISO-8601 vs local expectations

The answer lies in how JavaScript (and most supporting libraries) determine week numbers.

JavaScript itself does not have a native getWeek() function, but most common implementations follow the ISO-8601 standard:

  • Weeks start on Monday
  • Week 1 is the first week of the year that contains at least four days in the new year
  • Week boundaries are calculated relative to Thursday

For 2025, that leads to the following result:

  • Monday, February 17, 2025 → still ISO week 7
  • Tuesday, February 18, 2025 → ISO week 8

So while this feels “wrong” locally, JavaScript is technically correct according to ISO-8601.

Why this matters in VCF Orchestrator

In Broadcom VMware VCF Orchestrator, JavaScript is often used to:

  • Schedule tasks
  • Generate weekly reports
  • Drive time-based logic in workflows
  • Integrate with external systems like ITSM or ticketing platforms

If your organization assumes Dutch calendar logic without explicitly coding for it, you can end up with off-by-one-week errors that are extremely hard to trace later.

The solution: make the week calculation explicit

To avoid ambiguity, I implemented an explicit ISO-week calculation in JavaScript and documented it clearly in the action itself. This ensures that anyone reading or reusing the code understands exactly which standard is applied.

Here is the action I use in Orchestrator:

function calculateCurrentWeek(dateNow) {
	function getISOWeekNumber(date) {
	    var d = new Date(date.getTime());
	    d.setHours(0, 0, 0, 0);
	    
	    // Adjust to the Thursday of the current week
	    d.setDate(d.getDate() + 3 - (d.getDay() || 7));
	
	    // Find the start of the year (first Thursday's week)
	    var yearStart = new Date(d.getFullYear(), 0, 4);
	    yearStart.setDate(yearStart.getDate() + 3 - (yearStart.getDay() || 7));
	
	    // Calculate the week number
	    var weekNumber = Math.round(((d - yearStart) / 86400000) / 7) + 1;
	
	    return weekNumber;
	}
	
	// Set variable
	var actionName = arguments.callee.name.substr(6);
	
	// Input validation
	if (!(dateNow instanceof Date)) {
	    throw new Error("[" + actionName + "] 'dateNow' must be a Date object");
	}
	
	// Calculate the week number
	var weekNumber = getISOWeekNumber(dateNow);
	
	// Return the result
	return weekNumber;
	
}

Takeaway

This is not a bug in Broadcom VMware VCF Orchestrator, nor in JavaScript itself. It is a reminder that date logic is never “obvious” in automation.

If your workflows depend on week numbers:

  • Decide explicitly which standard you use (ISO vs local convention)
  • Document that choice in your actions
  • Never rely on “what feels correct” for calendar logic

In automation platforms like VCF Orchestrator, these small details can make the difference between predictable workflows and subtle production issues that surface weeks later.

Your subscription has expired Aria Automation Orchestrator 8.18

After upgrading to VMware Aria Automation Orchestrator 8.18.1 update 2, I was greeted with a warning banner that read: “Your subscription has expired. The core product operations are unavailable.“. Here’s a screenshot of the message as it appears on the License page in Aria Automation Orchestrator — just in case you’re wondering how it looks in the UI.

Despite the product being fully licensed and working perfectly prior to the upgrade, this message appeared across the UI and disrupted basic functionality. While searching for answers, I found the official fix in Broadcom KB 380260, which turned out to be spot-on.

The Problem – Your subscription has expired

With the release of version 8.18, VMware introduced an updated licensing mechanism tied to Aria With the release of version 8.18, VMware introduced an updated licensing mechanism tied to the Aria Universal Suite Subscription. If your system had an expired Authentication Token, the application incorrectly flagged the license as invalid — even though your actual subscription was still valid.

So while everything was fine on the licensing side, the platform’s backend had issues validating the license properly.

What Was Affected:

At the time of the issue, the following core functionalities were completely disabled:

  • No workflows could run
  • No scheduled workflows were executed
  • No policies were triggered

This essentially rendered the product useless and unavailable for serving any customer platforms.

The Solution

Here’s what fixed it for me:

  1. SSH into the Aria Automation Orchestrator appliance.
  2. Run the following command to fix the issue: (vracli vro properties set –key com.vmware.o11n.license.check.automation-endpoint.enabled –value false).
  3. Wait for the services to stabilize, or reboot the appliance if needed.
  4. After a few minutes, the warning disappeared and all functionality returned to normal.

It was that simple — no need to re-upload the license, no need to redeploy anything. Just a simple command to run in the shell.

Final Thoughts

I’d suggest running this command as part of your post-upgrade validation checklist if you’re moving to Aria Automation 8.18 or later.

Have you seen similar issues after upgrades? Let me know on be-virtual.net — always happy to exchange notes.

Dell EMC VxRail NSX-T Considerations

Currently, I have been involved in a Dell EMC VxRail design & deployment with VMware Cloud Foundation on Dell EMC VxRail. There were some noticeable items that you need to consider when using the Dell EMC VxRail as your hardware layer in combination with VMware NSX-T as a network overlay. So it was time to write down the items that I have learned so far surrounding the VxRail NSX-T considerations.

This blog post is focused on the NSX design considerations that are related to the physical level when using the Dell EMC VxRail hardware.

At first, I am going to talk about VMware NSX-V because a lot of customers are already running Dell EMC VxRail in combination with NSX-V and need to move to NSX-T in some time.

VMware NSX-V

In case you are already using Dell EMC VxRail with VMware NSX-V. Your physical NIC configuration would in most cases look like one of the following:

  • Scenario 01: Dual port physical NIC – 10 Gbit
  • Scenario 02: Dual port physical NIC – 25 Gbit

The default configuration that I see in the field at this moment is based on a single dual-port card with either 10 Gbit or 25 Gbit. This is for fine for VMware NSX-V but not for his replacement…



VMware NSX-T

When using Dell EMC VxRail with VMware NSX-T you are required to use four physical NICs! This is because of the limitation surrounding the Dell EMC VxRail software that makes a “PowerEdge server” a “VxRail server”.

The first official Dell EMC statement from there VMware Cloud Foundation on VxRail Architecture Guide: “NSX-T based VI WLD will require additional uplinks, whatever uplinks were used to deploy the VxRail vDS cannot be used or the NSX-T N-VDS“.

The second official Dell EMC statement from there VMware Cloud Foundation on VxRail Architecture Guide: “Note: NSX-T will use the next two available vmnics that are both the same speed for every node in the cluster“.

So this leaves us with three scenarios provided by Dell EMC for the VxRail nodes:

  • Scenario 01: Quad-port physical NIC
  • Scenario 02: Quad-port physical NIC (two ports used) with dual-port physical NIC
  • Scenario 03: Dual-port physical NIC with dual-port physical NIC.


Advise

Dell EMC VxRail is the only hardware platform currently on the market that requires four physical NICs to operate with NSX-T. This means you have to make sure your hardware and datacenter are capable of supporting this requirement. You need to make some choices surrounding the physical network cards, network capacity and datacenter rack space.

So let’s start with my list of VxRail NSX-T considerations!

Physical Network Card

When you are at a point of buying the Dell EMC VxRail solution, buy at least a quad-port NIC configuration. Personally, I prefer the double dual-port NIC setup. As shown here below:

I prefer this hardware setup because of the hardware redundancy created by two cards with there separate chips and PCIe slots. This reduces the change of losing all your network connections when a physical NIC dies.

Another recommendation should be to buy physical NICs that support 25 Gbit. It is a minimum price difference and will make the setup more future proof.

Top of Rack (TOR)

As discussed in the last paragraph: when you move to VMware NSX-T you are forced to use four physical NICs in each VxRail node. After installing the card you need to make sure you have enough physical ports in your Top of Rack switches/Leaf switches.

At the customer where I am currently working, they are forced to increase there Top of Rack switches capacity from two ports per server with NSX-V to four ports per server with NSX-T. This meant a full redesign of there datacenter rack topology and network topology. The spine switches were also not able to connect with that amount of leaf switches.

Keep in mind: This is only required of course when you are running a decent amount of servers per rack. In the customer case, they are running 32 VxRail nodes per rack. This means they require at least 128 physical switch ports per rack without uplink ports counted.

Here is an overview of the scenarios as just described, the first is the NSX-V scenario and the second the NSX-T scenario.

Near future

I know that VMware & Dell EMC are currently working on a solution for the VxRail hardware but time will tell. At this point keep your eyes open when moving from NSX-V to NSX-T with Dell EMC VxRail. Customers how are deploying greenfield also need to be aware that they need additional network capacity.

So that wraps up my VxRail NSX-T Considerations blog post. Thanks for reading my blog post and see you next time!