F5 - fix 404 error when clicking on F5 object on canvas

If you get a 404 error in vRA when you click on the F5 object in the canvas, follow these steps to fix it.  This seems to be a bug with vRA that happens when multiple external vROs are sharing the same vRA.

The Problem

Dragging or viewing an F5 Component into the vRA blueprint canvas results in an error



If multiple vRA tenant exists for a vRA, the last vRA tenant to run the SovLabs Configuration workflow (for a new install or an upgrade) will have a working F5 XaaS. All of the other vRA tenants will now error.

Temporary Workaround

Get F5 XaaS component working for your tenant (most likely, it will error on all the other tenants for that vRA instance)

  1. Login to vRO client for the tenant that errored
  2. Click on Workflows tab
  3. Drill down folders SovLabs > Configuration > Subflows
  4. Run vRO workflow Process Modules Updates
    • Select the appropriate CAFE host
    • Type in “F5” as the module
    • Type in the tenant name
    • Select Yes for “updateF5DefaultRestipe”
    • Click Submit
  5. Workflow should be successful


Additional Thoughts


The purple/blue highlight “Update F5 Virtual XaaS” is the script task where I update a tenant’s F5 XaaS blueprint “F5 Virtual – SovLabs Modules” (which is the F5 component that you drag in)
An update was necessary because of the new fields we added for F5 (persistence profiles, profiles, member node settings, split out into 3 tabs)

In the scriptable, it calls:

var result = client.putWithVariables("tenants/{tenantId}/blueprints/{blueprintId}", bpObj, [cafeHost.tenant, blueprintId]);
bpObj = JSON structure of new/latest F5 XaaS blueprint
client = cafeHost.createRestClient(vCACCAFEServicesEnum.ADVANCED_DESIGNER_SERVICE);

Unsure why it causes the other tenants to lose its F5 form when the latest tenant runs SovLabs Configuration (which calls Process Module Updates), but it does… Perhaps to do with database?


Have more questions? Submit a request


Please sign in to leave a comment.