Removing a vCenter Endpoint from vRA 7.x

This post will walk through the process of removing a vCenter Endpoint from vRA 7.3. Before beginning it is a good idea to take a backup of the vRA database, and snapshot the vRA management stack. Ensure there are no existing virtual machines provisioned to the vCenter Endpoint we are removing. A reservation cannot be removed while virtual machines are assigned to it. Log into the vRA tenant web portal. You can check existing virtual machines from the Infrastructure tab under Managed Machines using the Reservation filter. Still on the Infrastructure tab, from the navigation pane on the left hand side select Reservations, Reservations. Select and Delete any reservations using compute resources associated with the vCenter Endpoint.

The next step is to remove the compute resources. Download the vRealize CloudClient here, at the time of writing the latest version is 4.4.0. Extract the contents to a Windows machine with access to the vRA management stack. In this example I am using one of the IaaS web servers. From an elevated command prompt run the VMware_vRealize_CloudClient-4.4.0-5511232\bin\cloudclient.bat file and accept the EULA. The first thing we will do for ease of use is to create an auto login file using login autologinfile and close down Cloud Client.

CloudClient

In the root directory of the extracted folder a file is created called CloudClient.properties. Open the file with notepad and enter the FQDN or IP address of the vRA appliance and IaaS load balance name in the appropriate fields, along with administrator credentials for both.

CloudClientLogin

Open back up the VMware_vRealize_CloudClient-4.4.0-5511232\bin\cloudclient.bat file in an elevated command prompt, by default the auto login file will be used. Accept any certificate warnings when prompted.

When using Cloud Client you can tab out to see available commands. We’ll need the following:

vra computeresource list displays a list of compute resources

vra computeresource inactive list displays a list of inactive compute resources

CloudClient1

At this stage before actually deleting the compute resources we need to stop the VMware vCloud Automation Center Agent service on the vRA Agent servers.

vra computeresource inactive remove removes the listed inactive compute resources

continue confirms deletion of the compute resources

agents stopped confirms agents are stopped, at this point the compute resources will be removed

CloudClient2

Go back into the vRA tenant web UI, from the Infrastructure tab check in Compute Resources, or Endpoints, Fabric Groups. Click the fabric group previously containing the compute resources, they have now been removed.

The final step is to remove the endpoint, this can be done in the web UI under Infrastructure, Endpoints, Endpoints. Select the endpoint and click Delete. Alternatively the endpoint can be removed from Cloud Client using vra endpoint remove --id <endpoint> where <endpoint> is the endpoint name. Remember to remove the CloudClient.properties auto login file.

Upgrading to vCenter Server 6.5 Update 1

VMware have released the first major update to vSphere 6.5. This post will walk through how to update the vCenter Server Appliance (VCSA) from 6.5 to 6.5 U1. The new features in the latest release are listed here. The official VMware blog goes into further detail here, and of course the release notes cover the important technical information here.

Prior to updating vCenter ensure you have verified the compatibility of any third party products such as backups, anti-virus, monitoring, etc. Also cross-check the compatibility of other VMware products using the Product Interoperability Matrix. Since we are updating vCenter Server 6.5 to 6.5 U1 I am assuming the usual pre-requisites such as FQDN resolution, time synchronization, relevant ports open, etc. are already in place, and all hosts are running at least ESXi version 5.5. For more information on the requirements for vCenter Server 6.5, or if you are upgrading from an earlier version, the following posts may be of use:

Before beginning the update process take a backup and snapshot of the vCenter Server Appliance. There is downtime during the update but this is minimal – around 10 mins to update and reboot using an ISO as an update source, when using the online repository the update time may vary depending on your internet connection.

VAMI Update

The easiest way of updating the vCenter Server is through the VAMI (vCenter Server Appliance Management Interface). Browse to https://vCenter:5480, where vCenter is the FQDN or IP address of the vCenter Server. Log in as the root user.

VAMI1

Select the Update option from the navigator.

VAMI2

Click the Check Updates drop-down. If the VCSA has internet access then select Check Repository to pull the update direct from the VMware online repository.

If the VCSA does not have internet access, or you’d prefer to provide the patch manually then download the relevant patch from VMware here (in this case VMware-vCenter-Server-Appliance-6.5.0.10000-5973321-patch-FP.iso) and attach the ISO to the CD/DVD drive of the VCSA in the virtual machine settings. Back in the VAMI update page select the Check Updates drop-down and click Check CDROM.

VAMI3

Details of the available update from either the online repository or attached ISO are displayed. Click Install Updates.

VAMI4

Accept the EULA and click Install to begin the installation.

VAMI5

When the update process has completed click OK. From an attached ISO the installation took around 5 minutes.

VAMI7

The updated version and release date should now be displayed in the current version details. Finally, to complete the upgrade reboot the vCenter Server Appliance. Select Summary from the navigator and click Reboot.

VAMI8

CLI Update

Alternatively the vCenter Server Appliance can be updated from the command line. Again, either using the online repository or by downloading the patch from VMware here (VMware-vCenter-Server-Appliance-6.5.0.10000-5973321-patch-FP.iso or latest version) and attaching the ISO to the CD/DVD drive of the VCSA in the virtual machine settings. For more information on patching the vCenter Server Appliance using the appliance shell see this section of VMware docs.

Log in to the vCenter Server appliance as root. First stage the patches from your chosen source using either:

  • software-packages stage --iso --acceptEulas stages software packages from ISO and accepts EULA.
  •  software-packages stage --url --acceptEulas stages software packages from the default VMware online repository and accepts EULA.

Next, review the staged packages, install the update, and reboot the VCSA.

  • software-packages list --staged lists the details of the staged software package.
  • software-packages install --staged installs the staged software package.
  • shutdown reboot -r update reboots the VCSA where ‘update’ is the reboot reason. Use -d to add a delay.

CLI4

ESXi 6.5 FCoE Adapters Missing

After installing or upgrading to ESXi 6.5 FCoE adapters and datastores are missing. In this case the hardware in use is a HP ProLiant BL460c Gen9 server with HP FlexFabric 10Gb 2-port 536FLB adapters, although this seems to have been a problem for other vendors (see here) and versions too.

This issue should be resolved with a driver provided by the vendor which has the FCoE auto discovery on boot parameter enabled. Cross reference your hardware against the VMware Hardware Compatibility Guide here, and confirm you are using the correct version of the bnx2fc driver and firmware. If no updated driver is available from the vendor then review the workarounds outlined below.

Stateful Installs

Credit to this article, SSH onto the host and run the following commands.

esxcli fcoe adapter list lists the discovered FCoE adapters, at this stage there will be no results.

esxcli fcoe nic list lists the adapters available as potential FCoE candidates. Locate the name of the adapter.

esxcli fcoe nic enable -n vmnicX enables the adapter, replace vmnicX with the adapter name, for example vmnic2.

esxcli fcoe nic discover -n vmnicX enables discovery on the adapter, replace vmnicX with the adapter name.

esxcli fcoe adapter list lists the discovered FCoE adapters, you should now see the FCoE adapters listed.

The storage adapters should now be showing in the vSphere web client, however if you are using stateless installs with Auto Deploy, then this workaround is not persistent and is lost at reboot.

storageadapters2

Stateless Installs

Credit to this article, we were able to create a custom script bundle to enable discovery on the FCoE adapters as part of the deploy rule with the steps below. Custom script bundles open up a lot of possibilities with Auto Deploy, but at this stage they are CLI only. I also noticed that if you create a deploy rule with a script bundle from the CLI, although it shows in the GUI if you then edit that rule in the GUI (for something unrelated, e.g. updated host profile) then it removes the script bundle without warning. So this is something you would need to weigh up against your environment, if you are already using CLI to configure deploy rules it shouldn’t be a problem.

PowerCLI can now be installed directly through PowerShell, if you don’t already have PowerCLI installed see here.

  • First up we’ll need to create the script on a Linux / Unix system. I just used a test ESXi host we had kicking about over SSH. Type vi scriptname.sh replacing with an appropriate name for your script.
  • The file will open, type i to begin editing.
  • On the first line enter #!/bin/ash followed by the relevant enable and discover commands from the section above. You can see in the example below the commands for enabling vmnic2 and vmnic3 as FCoE adapters.

ssh1

  • Press escape to leave the text editor and type :wq to save changes to the file and close.
  • Next we need to create the script bundle that will be imported into Auto Deploy. Type tar -cvzf bundlename.tgz scriptname.sh

ssh2

  • Copy the script bundle with the .tgz extension to your local machine, or the computer from where you will be using PowerCLI to create the deploy rule. In my case I copied the file over with WinSCP.
  • You should also have an ESXi image in zip format, make a note of the location. Add the script bundle and the ESXi software depot by running the following commands Add-ScriptBundle location\bundlename.tgz and Add-EsxSoftwareDepot location\file.zip. If you need further assistance with building custom images or using PowerCLI to manage Auto Deploy see the VMware Auto Deploy 6.x Guide and How to Create Custom ESXi Images posts.

ps1

  • Build the deploy rule using your own variables, again if you’re already using Auto Deploy I’m assuming you know this bit, we’re just adding an additional item in for the script bundle. See the guide referenced above if you need assistance creating deploy rules. I have used:
    • New-DeployRule -Name "Test Rule" -Item "autodeploy-script","HPE-ESXi-6.5.0-Build-5146846", LAB_Cluster, -Pattern "ipv4=192.168.0.101" | Add-DeployRule

ps2

  • The deploy rule is created and activated, I can now see it in the Auto Deploy GUI in the vSphere web client, with the associated script bundle. When the host boots from the deploy rule the script is extracted and executed, and the FCoE adapters are automatically enabled and discovered on boot.

autodeployGUI

  • If you don’t use the | Add-DeployRule parameter then the deploy rule will be created but show inactive. You can activate using the GUI but do not edit the rule using the GUI or the script bundle will break.
  • If you are updating an existing image then don’t forget to remove cached rules by remediating host associations, under the Deployed Hosts tab.

Adding Custom Resource Actions for vRA 7.x

This post will walk through adding a resource action for vRealize Automation 7.x, mapped to a custom vRO workflow. The steps below assume that the vRO instance has been integrated with vRA.

Log into the vRealize Automation portal as a user with service architect permissions. From the Design tab select XaaS and Resource Actions. Any existing resource actions are listed. Click New.

vra1

Map the resource action to the relevant vRO workflow. In this example I am using a workflow that adds a virtual machine to a backup job. You can use any workflow that has been configured to accept an input parameter from a vRA item. For this particular case we are using the VC:VirtualMachine parameter which passes the virtual machine provisioned by vRA.

vra2

If not already populated select the relevant input mappings. In this case the resource type is IaaS VC Virtual Machine, the input parameter matches up with the parameter configured in the vRO workflow (whatever you have named it, vmObj here), and this maps to the VC:VirtualMachine orchestrator type.

If your vRO parameter does not have a corresponding mapping already in vRA or ready to be imported into vRA then you can create a new / custom resource mapping in the Resource Mappings page.

vra3

Enter a name and description for the resource action. Configure the remaining settings as appropriate, you have the option to set a provisioning or disposal type (leave blank if neither) and have the action always available or only when a certain criteria is met.

If you un-select the hide catalog request information page the user is prompted for a description and reason for requesting the resource action.

vra11

Once you have completed the details page click Next.

vra4

Edit the form to represent how you want the action to be displayed to users. Most of this configuration should be obtained from the vRO workflow so you may not need to make changes here. Click Finish.

vra5

The new resource action is now listed as a draft. To start using the action select it and click Publish.

vra6

Now select the Administration tab and Catalog Management. Open the Actions page, the new resource action we created should now be displayed.

If you want to change the icon of the resource action you can do so by selection the action and clicking Configure. There are a number of useful vRA icons available here, including sample icons for day 2 actions. In my example I am unable to update the icon which seems to be an issue with custom actions created in vRA 7.2; resolved in 7.3 as per this KB article.

vra7

The next step is to assign our custom action to an entitlement. Open the Entitlements page and select the relevant entitlement. Click the Items & Approvals tab, under Entitled Actions click the green plus symbol. Locate the new resource action and select the check box to add it to the entitled actions. Click Ok and Finish.

vra8

To confirm the configuration has worked browse to the Items tab and select Machines. Any virtual machines that have the custom resource action added to the entitlement will show the new action in the drop-down Actions menu.

vra9

When I select the new action I am presented with the action form as per the design canvas we saw earlier. In this example I select the backup job from the drop-down list of jobs that my vRO workflow has pulled from the backup server, and click Submit. The VC:VirtualMachine parameter is then passed through to the next stage of the workflow, which adds machine to the selected backup job.

vra10

VMware vRealize Business for Cloud Install

VMware vRealize Business for Cloud provides automated cost analysis and consumption metering; allowing administrators to make workload placement decisions between private and pulic clouds based on cost and available services. Furthermore infrastructure stakeholders have full visibility of virtual machine provisioning costs and are able to accurately manage capital expenditure and operating expenditure. For more information see the vRealize Business product page, you can try vRealize Business for Cloud using the Hands on Labs available here.

This post will walk through the installation of vRealize Business for Cloud 7.3; we’ll be provisioning to a vSphere environment running vRealize Automation 7.3. Each vRealize Business instance scales up to 20,000 virtual machines and 10 vCenter Servers, remote data collectors can be deployed to distributed geographical sites. vRealize Business is deployed in OVA format as a virtual appliance, you should ensure this appliance is backed up appropriately. There is no built in HA or DR functionality within vRealize Business, but you can take advantage of VMware components such as High Availability, Fault Tolerance, or Site Recovery Manager. Logs can be output to a syslog server such as vRealize Log Insight.

vRB_Launchpad

Requirements

  • vRealize Business for Cloud must be deployed to an ESXi host, and can be used to mange vCenter Server, vCloud Director, vCloud Air, vRealize Automation, and vRealize Operations Manager.
  • vRB 7.3 is compatible with vCenter and ESXi versions 5.5 through to 6.5, and vRealize Automation verisons 6.2.4 through to 7.3 (latest versions at the time of writing).
  • For compatibilty with other VMware products see the VMware Product Interoperability Matrix.
  • The vRB appliance requires 8 GB memory, 4 vCPU and 50 GB disk (thick provisioned).
  • If you use any remote data collectors the memory on these appliances can be reduced to 2 GB.
  • vRealize Business for Cloud is licensed as part of the vRealize suite, per CPU, or in packs of 25-OSI.
  • There are 2 available editions; standard and advanced. Features such as public cloud costing require the advanced version, for more information see the feature comparison section of the product page.
  • The web UI can be accessed from IE 10 or later, Chrome 36.x or later, and Firefox 31.x and later.
  • Time synchronization and name resolution should be in place across all VMware components.
  • For a full list of pre-requisites including port requirements see here.

Before beginning review the following VMware links:

Installing vRB

Download the VMware vRealize Business for Cloud 7.3 OVA file here. Log into the vSphere web client and right click the datastore, cluster, or host where you want to deploy the virtual appliance. Select Deploy OVF Template and browse to the location of the OVA file.

  • Enter a name for the virtual appliance and select the deployment location, click Next.
  • Confirm the compute resource and click Next.
  • Review the details of the OVF template and click Next.
  • Accept the end user license agreement and click Next.
  • Select the storage for the virtual appliance, ensure the virtual disk format is set to Thick provision eager zeroed, and click Next.
  • Select the network to attach to the virtual appliance and click Next.
  • Set the Currency, note that at this time the currency cannot be changed after deployment. Ensure Enable Server is checked, select or de-select SSH and the customer experience improvement program based on your own preferences. Configure a Root user password for the virtual appliance and enter the network settings for the virtual appliance in the Networking Properties fields.
  • Click Next and review the summary page. Click Finish to deploy the virtual appliance.

Once the virtual appliance has been deployed and powered on open a web browser to https://vRB:5480, where vRB is the IP address or FQDN of the appliance. Log in with the root account configured during setup.

vRB_Mgmt

Verify the settings under AdministrationTime Settings, and Network. At this stage the appliance is ready to be registered with a cloud solution. In this example I will be using vRealize Automation, for other products or further information see the install guide referenced above. Return to the Registration tab and ensure vRA is selected.

vRB_Register

Enter the host name or IP address of the vRA appliance or load balancer. Enter the name of the vRA default tenant and the default tenant administrator username and password. Select Accept vRealize Automation certificate and click Register.

Accessing vRB

vRealize Business for Cloud can be integrated into vRealize Automation, or you can enable stand-alone access. To access vRB after integrating with vRA log into the vRA portal. First open the Administration tab, select Directory Users and Computers, search for a user or group and assign the relevant business management roles. A user with a business management role has access to the Business Management tab in vRA.

vRB_Roles

Optional: to enable stand-alone access first enable SSH from the Administration tab. Use a client such as Putty to open an SSH connection to the virtual appliance, log in with the root account. Enter cd /usr/ITFM-Cloud/va-tools/bin to change directory, enter sh manage-local-user.sh and select the operation, in this case 5 to enable local authentication.

ssh

If you want to create new local users user option 1 and enter the username and password, when prompted for permissions VCBM_ALL provides administrator access and VCBM_VIEW read-only. You can also log in to the web UI with the root account, although it would be better practice to create a separate account.

Disable SSH from the Administration tab if required. Wait a few minutes for the services to restart and then browse to https://IP/itfm-cloud/login.html, where IP is the IP address of your appliance. If you try to access this URL without enabling stand-alone access you will receive a HTTP Status 401 – Authentication required error message.

vRB Configuration

We will continue with the configuration in the vRA portal, open the Administration tab and click Business Management.

vRB_Connections

Expand License Information, enter a license key and click Save. Expand Manage Private Cloud Connections, configure the required connections. In this example I have added multiple vCenter Server endpoints. Open the Business Management tab, the Launchpad will load.

vRB_Launchpad

Select Expenses, Private Cloud (vSphere) and click Edit Expenses. At this stage you will need the figures associated with hardware, storage, and licensing for the environment. You can also add costs for maintenance, labour, network, facilities, and any other additional costs.

vRB_Expenses_vSphere

Once vRB is populated with the new infrastructure costs utilisation and projected pricing will start to be updated. Consumption showback, what-if analysis, and public cloud comparisons can all be accessed from the navigation menu on the left hand side. For further guidance on getting the most out of vRB see the vRealize Business for Cloud User Guide.

vRB_Operational

How to Create Custom ESXi Images

The ESXi Image Builder is a useful tool allowing administrators to create custom images built on vendor specific images, or vanilla ESXi images, with additional updates or third party drivers. Custom images can be downloaded in ISO or ZIP format, or used with Auto Deploy to boot hosts using deploy rules.

Traditionally ESXi Image Builder has been a subset of Power CLI cmdlets, which you can still use. However in this post we’ll walk through the Image Builder GUI introduced to the vSphere web client with version 6.5. You’ll need to be running vCenter 6.5 to make use of the Image Builder GUI, for assistance with upgrading see one of the following posts: vCenter Appliance 6.5 UpgradeWindows vCenter 6.5 Upgrade, or Migrating Windows vCenter Server to VCSA 6.5. For more information on Auto Deploy see the VMware Auto Deploy 6.x Guide.

Further reading from VMware: Getting Started with the New Image Builder GUI in vSphere 6.5, Using vSphere ESXi Image Builder with the vSphere Web Client.

Enable Image Builder

The ESXi Image Builder can be enabled from the vSphere web client, log in as an SSO administrator. From the home page select System Configuration.

image1

Under Nodes select the appropriate vCenter Server and click the Related Objects tab. A list of services is displayed. The ImageBuilder Service and Auto Deploy services need to be started and set to automatic for the GUI to be accessible (even if you’re not using Auto Deploy in your environment).

image2

Log out of the web client and log back in, you should now see the Auto Deploy option on the home page.

Using Image Builder

Click the new Auto Deploy icon from the home page.

autodeploy

Select the Software Depots tab. Software depots contain images or software packages. Use the Add Software Depot icon to add an online software depot or a new custom depot which you can add images to later. Use the Import Sofware Depot to upload a zip file such as an ESXi image. Unlike the command line utility, any software depots you add to the GUI are saved there when you return.

Let’s go ahead and make a start. First we need a copy of ESXi to work with, this can be a vendor optimized image or a vanilla copy of ESXi. In this example I have added a software depot containing the HPE optimized ESXi image. We are going to add the Nimble Connection Manager to the image, so I’ve also added the Nimble-NCM zip. You can add any third party drivers or software that vibs are provided for. I’ve created a custom software depot where my new image will be saved. You can add as many different software depots as you like.

GUI1

Next we want to take the base ESXi image and clone it so we can add some additional software packages. Select the software depot containing the base ESXi image. Highlight the image and click Clone. Enter a name, description and vendor for the new image, and select a software depot where the new image will be stored. In this case I have chosen the new custom software depot I created above.

GUI2

The software packages from all software depots that were added to Auto Deploy will be listed. Select the package(s) that you want to apply. Set the acceptance level of the image and click Next. The acceptance level determines which level VIBs are accepted for installation; VMware Certified being the most strict and Community Supported the most open. For further information on vib signature levels see this page.

GUI3

Review the details on the summary page and click Finish.

GUI4

Now when I click the custom software repository I can see my new ESXi image. The bottom right task pane will show a list of software packages included in the image when selected.

GUI5

Once all the required software packages have been added to the image you can download the ESXi image by right clicking it and selecting Export Image Profile. Alternatively you can build deploy rules to automatically boot hosts from a custom image with Auto Deploy, for more information review the VMware Auto Deploy 6.x Guide.

VM Security Tags with NSX Firewall

This post will walk through virtual machine security tags; how we can create tags, automatically add virtual machines with tags to a specific security group, and build associated NSX firewall rules. As a bonus we’ll also apply a security tag to a vRA blueprint, allowing vRA provisioned machines to automatically receive a security tag and apply any corresponding NSX firewall rules.

Security tags and groups allow us to identify virtual machines with a common value, such as business department, support group, workloads, and so on. By applying security tags to virtual machines, and/or adding virtual machines to security groups, we can control security at a custom defined level, independent of the underlying infrastructure. Virtual machines can have multiple tags, allowing administrators to identify different values upon which to act. Many third party anti-virus solutions with NSX integration use security tags to protect and quarantine virtual machines depending on their health status.

The steps below assume that NSX is installed and working, for more information on installing the required components see the following series of posts.

NSX Install Guide Part 1 – Mgmt and Control Planes

NSX Install Guide Part 2 – Data Plane

NSX Install Guide Part 3 – Edge and DLR

Creating Security Tags and Groups

From the vSphere web client browse to Networking & Security, click NSX Managers, and select the appropriate NSX Manager. Open the Manage tab, then Security Tags. Existing security tags are listed, some third part plugins such as AV may also add and use security tags. To create a new security tag click the New Security Tag icon. Enter a name for the security tag, and a description if required, then click Ok.

Tags1

Security tags can be applied to virtual machines manually in the page referenced above, or through an automatic provisioning solution such as vRealize Automation.

Next, select the Grouping Objects page. Under Security Groups, click the Add New Security Group icon. Enter a name and description if required.

Group1

Go to the third option: Select objects to include. Change the Object Type in the drop-down to Security Tag. Select the new security tag we created earlier.

Group2

Review the details on the summary page and click Finish.

Group3

The security group has now been created, and any virtual machines that use the security tag we included are automatically added to the group. You can create multiple security tags and groups for different departments, applications, or however you want to segregate these out.

Group4

Creating NSX Firewall Rules

Our new security group / tag setup can be used to configure NSX firewall rules. Still under Networking & Security in the vSphere web client; select Firewall.

If you have already configured NSX firewall rules you’ll be familiar with this page, and likely have a number of sections and rules already configured. You can edit an existing rule or create a new one in the relevant section. To create a new section use the Add Section (folder) icon. Click the green plus icon to add a new rule, or the edit icon to edit an existing rule.

Firewall1

When configuring the rule you can set the source, destination, or both to use a security group. Change the Object Type drop-down to Security Group, and select the new security group we created earlier.

Firewall2

Remember to click Publish Changes when you’re done. For assistance with creating NSX firewall rules see this section of the NSX Documentation Center.

Adding Tags to vRA Blueprints

The use of security tags with blueprints requires NSX to be integrated with vRA. If you haven’t already done so you can follow the steps outlined in the VMware post Part 1 of Integrating NSX with vRealize Automation. You’ll also need an understanding of how to create blueprints, again there is more information on this in the VMware post Part 2 of Integrating NSX with vRealize Automation if you need it.

To add a security tag to a virtual machine provisioned by vRA we must add it to the appropriate blueprint. After adding security tags and/or groups to NSX Manager we need to run a data collection so that vRA is showing up to date information. From the vRA portal browse to the Infrastructure tab, select Compute Resources, Compute Resources. Move the mouse cursor over the compute resource and click Data Collection. Scroll down to Network and Security Inventory and click Request now. The sync will take a couple of minutes, you can leave the page during this time.

vra1

Next open the Design tab and select Blueprints. We can add a security tag to an existing blueprint, or create a new one. In the design canvas click Network & Security from the list of categories. Locate Existing Security Tag and drag this onto the canvas. Alternatively you can use a security group at this stage if you’d prefer.

vra2

Select the security tag from the list of existing tags. From the design canvas select the virtual machine and open the Security tab. Tick the referenced security tag to associate it with the virtual machine. Click Save and Finish to save the changes to the blueprint. Any virtual machines provisioned from this blueprint are now tagged with the security tag (or group) selected.