vRealize Suite LifeCycle Manager (vRSLM) has now been around for a while and if you are a vRealize or vCloud Suite license holder this is definitely a product that should be part of our VMware portfolio. I am a bit backward because in my last post is showed how to upgrade your vRA environment using vRSLM and only now will I show how to actually install vRA which actually just comes out of necessity because one of my colleagues accidentally delete all my lab servers 🙂

For this post, I am using the latest vRSLM 1.3 and will be deploying a distributed vRA 7.4.

If you already have the OVA downloaded then you can import it under the Product binaries tab.

Verify that you have vRealize Automation binaries status as completed.

If you using a self-signed certificated in your environment (not recommended), then create a self-signed wildcard certificate for vRealize Suite product deployments.

Best is to generate a single SAN certificate with all the product or management virtual host names or a wildcard certificate and provide this certificate when you create the environment for the first time. This ensures support for post provisioning actions such as Add Products and Scale Out.

As with most of my other blog posts, I am just providing a step by step guide for quick reference. Please refer to the documentation here for detailed information and please read the vRealize Automation 7.4 Release Notes known issues section which is updated regularly and helps you to be better prepare for the upgrade.

My environment consists of a distributed vRealize Automation running version 7.2 with an external clustered vRealize Orchestrator, which I am upgrading and not migrating to 7.4 Build 8182598. This will be a similar process if you have vRA 7.1 and greater. If you have an older version, refer to VMware’s documentation here.

The in-place upgrade process for the distributed vRA environment happens in 3 stages in the following order:

Check that the service “Distributed Transaction Coordinator” is running.

The primary IaaS Website node (Model Manager data is installed) must have JAVA SE Runtime Environment 8, 64 bits, update 161 or later installed, and also verify JAVA_HOME environment variable is set correctly after the upgrade.

If using embedded Postgres DB in a distributed vRA environment

On master vRA node, navigate to /var/vmware/vpostgres/current/pgdata/

Close any opened files in the pgdata directory and remove any files with a .swp suffix

Verify the correct ownership of all files in this directories: postgres:users

VMware’s vRealize Suite of Products are great, and each provides a lot of features and capabilities, and VMware has been working hard on integration between the products. However, these products are very much standalone with no cohesion between them from a lifecycle management perspective. This creates a lot of management overhead to install, upgrade, configure and manage all these products, as well the additional solution extensions.

In comes vRealize Suite LifeCycle Manager (vRSLCM) which is a relatively new product and is available to all customers with a vRealize Suite license. It automates the installation, configuration, and upgrading of the following products:

vRealize Automation

vRealize Operations Managers

vRealize Log Insight

vRealize Business for Cloud

In this blog, I am going to provide the steps on how to import an existing distributed Enterprise vRA 7.2 environment and perform the upgrade to 7.4 using vRSLCM 1.2.

Let’s start off with the initial creation of the environment, which does require a lot of information up front, but once you create or import products into the environment at a later time, it will make use of this stored environment information.

Log in to your vRSLCM

Select Create Environments

Enter Environment Data

Data Center (this you should have created during the initial configuration of your vRSLCM environment)

Environment Type

Environment Name

Administrator email

Default root password

Click Next

Create Environment

Check the box for vRealize Automation

Since we already have an environment that we need to import, select the import Radio button.

Click Next

EULA

Scroll down to bottom.

Check the box to accept the terms and conditions.

License

Either pick a vRealize Suite license which will populate from your my.vmware.com account, or enter one manually.

Click Next

Infrastructure Details (This information is used if you deploy new products)

Select vCenter Server where your vRealize Suite products reside in.

Select Cluster

Select Network

Select Datastore

Select preferred Disk format for product deployments.

Click Next

Network (This information is used if you deploy new products)

Enter default gateway of the network where your vRealize Suite products are deployed or will be deployed too.

Enter Domain Name

Enter search path

Enter DNS

Enter Netmask

Click Next

Certificates (I import a wildcard certificate or you can use multi-domain certificate would be a good choice to simplify the process)

Click Next to use the self-signed generated certificate or click the import certificate button to add existing wildcard or SAN certificate.

Click Next

Import (Since we selected import we now get ask questions about our existing environment)

Enter vRA root password

Enter vRA Default Administrator password

Enter Tenant User name.

Selecting the “administrator” user works just fine here.

Enter vRA Primary Node FQDN

Enter IaaS Username.

I used the domain service account assigned to all IaaS servers

Default vRA Tenant name is select “vsphere.local”

Enter vRA Tenant password

Enter IaaS Password for the domain account.

Select vCenter Server from the drop-down where the vRA server is running on.

Click Next

Review summary

Click Download configuration to save the JSON file for later use.

Click Submit

This will run for a while to configure the environment and import vRA

If it fails, you have a couple of options

Review the requests

Under actions select retry and verify the information that you have entered.

Delete the environment and start over (1.2 provides the ability to specify if you also want to delete the VMs when you delete a fully configured environment, definitely not recommended to do so in most cases!)

If you want to pause the import, you can always come back later and resume\

Verify the vRA product environment

Select Environment tab on the left side

Select View details of the newly created environment

Verify that all the information of your distributed vRA environment is accurate. vRSLCM collects all your VIP names, vRA-, IaaS- and Database Servers as well as where each component resides.

I just recently got back from a productive VMware Partner Empower Conference and since then I have been trying make some time to grind through the installing and upgrades of 10 new product releases. (Sorry I am a bit behind in getting this blog post publish) Yes, you heard correct 10! I do hope VMware in the future consider staggering the product release as well as align the product compatibility.

Improvement in the handling items in an in-progress state. This was a big pet peeve of mine which has finally been addressed!

Message board portlet security has been enhanced with a whitelist for URLs

Multitenancy in vRealize Orchestrator is great since now we do not have to deploy multi vRO environments for different tenants.

vRealize Orchestrator Appliance 7.4.0

Multitenancy in vRO, need we say more! Allows for full isolation of content items and execution and no more need to deploy separate vRO environment for tenants.

Web-based Clarity UI update with new monitoring dashboards for workflow runs and metrics to monitor and troubleshoot workflow runs including centralized log views.

vRealize Code Stream 2.4

General defect fixes and improvements.

vRealize Business for Cloud 7.4.0

Note:

If you are running vRBC 6.x.x a direct upgrade is not possible and you must first upgrade to 7.3.1!

If you upgrade to 7.4.0, any vRealize Automation VMs that are deleted in the current month before the upgrade will be missing in the current months vRA Report. There is currently no fix and the workaround is to download the vRA Report before you upgrade. KB 2151835

Enhancements to the VMC on AWS assessment with FTT and Erasure coding.

Pricing and Chargeback capabilities enhancements

For vCloud Director, storage policy driven pricing is now available.

For vCD, you can define T-Shirt sizes for Pay-as-you-go VMs. This is cool and I wish we can get this in vRA as well for Component Profile!

Apply differential rate for vCPU and Memory, that is beyond the guaranteed resources

I do not think that enough people are aware of this Fling, and that is really unfortunate.

First I want to take a step back and provide some history as to how this came about. As most of you know, there is no easy way to live migrate a VM between different vCenter Servers that are not in Enhanced linked mode, which connects multiple vCenter Server systems together by using one or more Platform Services Controllers.

Some methods I have used in the past:

Host migration to target vCenter Server:

Remove the managed ESXi host from the source vCenter and add it to the target vCenter and then perform a regular vMotion. This method, however, comes with a lot of caveats for instance in order to remove the ESXi hosts all the ports groups needs to be on Standard Switches so this requires a migration from VDS to VSS. Additional information available here

Enhanced linked mode

Setup enhanced linked mode between vCenter servers and perform a vMotion or Storage vMotion between the vCenter Servers, but this solution is not ideal when the source vCenter Server will get decommissioned. There is a way using supported workflows to remove ELM but is not supported by VMware so there is that! Good article by William about splitting vCenter Servers in ELM here.

Hybrid Cloud Extention (HCX)

HCX is another option that I am very excited about trying in near future which provides vMotion, Bulk Migration, WAN optimization and automated VPN with Strong Encryption. I have tested the tool for migration between on-prem and VMC on AWS and all I can say it is a game changer. Some more on that later in the year…

So getting back to why we are here! With not having the ability to vMotion between 2 non-ELM vCenter Servers, William Lam took it upon himself to write a script using the vSphere API with PowerCLI that finally provides the sorely missed capability to vMotion a VM between 2 vCenter Servers that are in different domains! So naturally, the evolution of making the script easier to consume is to provide a nice looking GUI with a fling!

Here you can find the Fling written by Vishal Gupta and William Lam. Props to both for all the time and effort to provide such a value-added feature.

Update 05.07.18:

Version 2.0 has been released which brings some great new enhancements, especially the top 3 listed below.

Added support to select individual host as the placement target

Added support for migrating VMs with shared datastore

Added clone functionality in addition to relocate

Added resource summary details for placement targets

Added a prompt to verify site thumbprint during SSL verification

Added a link to refresh VM list in the inventory view

Updated REST APIs to add operation type parameter

To run the fling you need => vCenter Server 6.0 and => Java Runtime 1.8.

To start the fling open a command prompt and type the following:

# java -jar xvm-2.0.jar

this will start the fling on port 8080 on the localhost.

If you want to change the port because it is in use, add the following flag:

So back to why we are here! When you have a hybrid cloud strategy and have to move applications to the cloud you definitely want to know a couple of things:

Which VMs are sitting idle or are over-provisioned on resources?

vRealize Operations (vROps) should be your go-to tool to identify all these VMs

How much will cost to place my VMs into any of Cloud Solutions available out there, including VMC on AWS?

vRealize Business for Cloud should be your go-to tool to provide pricing for different cloud-based solutions on a selected VM/application.

If you have multi-tiered applications, do you know the dependencies between the VMs and on which port/s they communicate with?

There are a lot of tools available that can provide application dependency mappings, but for this exercise, we are just looking at vRealize Network Insight (vRNI).

Let’s look at the steps to create an application dependency mapping, which is very similar to the steps you will use to create your micro-segmentation firewall rules.

Step 1: Select the initial VM that you have identified for the application.

Using VRNI powerful search capabilities, type the query “VM where name = ‘vmname.’

For the duration, if you have collected information for a while, then select maybe the last 7 days as your time frame

Click Search

The VM can be selected in different ways like:

Path and Topology -> VM

Entities -> VM

This will show information about the VM, click on the VM name.

Click on Flows in the toolbar

Review the VM Flows – Allowed and VM Flows – Denied

This shows all the flows to and from the selected VM

Click on the 3 vertical dots and select “Export as CSV.”

This exported document provides columns for all source and destination VMs that are connecting to your selected VM. Use this to start your application dependency mapping by creating an application in vRBC.

Select Entities -> Applications

Click Add Application

Enter Application Name

Enter Tiers and conditions to identify the VM or IP address

Add the VMs that you have identified as Source and Destination VMs in the flows.

You can also add more conditions to fine tune the VM select and also add additional Tiers.

Select Analyze Flows

Click Save

Step 2: Select the application, and add any additionally identified entities as the first hop.

Select Security -> Applications

Under scope drop-down select Application

Select Application name created in step 1

For Duration you can select anything but 7 days would be good to cover all different connectivity scenarios that might occur.

Click Analyze

On the Micro-segmentation view

Under “Group By” select VM

Under “Also show groups for” select All

Under Flow, Types select “All allowed flows.”

This will provide you with a presentation of how your application VMs are talking with one another

However, more importantly, you will see “other entities,” in grey boxes, which is what we are really interested in:

You can also filter based the groups to show all the entities associated with the groups below

Virtual

If you select virtual, you will be presented with a list of all the VMs that communicate to the applications, and have not yet been identified.

Again you export the CSV.

Review these VM’s and add them to the application.

Physical

If you select physical, you will be presented with a list of IP addresses for all the physical servers are you connecting too in your environment.

Review these VM’s and add the physical IP address to your application.

Shared Virtual

If you select Shared Virtual, you will be presented with a list of VMs that are connected to all the VMs in your application.

Review these VM’s and add them to the application.

Internet

If you select Internet, you will be presented with a list of public IP addresses that your application is connecting too.

Review these public IP addresses and take note of them

Step 3: Manually create your application dependency mapping

If you really want to see how deep the rabbit hole goes then repeat step 2.

This will provide additional virtual, physical, shared and internet entities, based on the updated application.

Unfortunately is no way in vRNI to show a network connectivity diagram of the application like you were able to see in VIN so you would have to create your own Visio, making use of the flow diagram or exported CSVs to identify individual connectivity.

This is my own method and not sure if right or wrong, but if anyone has figured out a different or better way, please let me know!

With pretty much “the swipe of your credit card,” you can get a login and start building your SDDC and be up and be running in a matter of hours.

It has some great use-cases that I think customers should really consider, especially if you have a cloud initiative, disaster recovery requirements or looking at building out new data centers. Here are some examples of those different use-cases:

Datacenter Consolidation

Datacenter Evacuation

Datacenter Expansion

Disaster Recovery (DRaaS with vSphere Replication and SRM)

Cyclical/Burst Capacity

Development and Testing

I do not want to go into crazy detail here since there are already a lot of guys in the community, who are much smarter than I am, who you should follow if you want to get in-depth knowledge of VMC on AWS. To name only a few:

What I do want to chat about it is how you get started and what do you need to think about from a requirement and architecture perspective during the initial setup.

Let’s start off with due diligence.

As mentioned there are a lot of good use cases for VMC on AWS but what do you need to consider to make the decision if this is the right solution for you. Here are a few things that I can think of, and please provide comments if you can think of any additional ones I can add.

How large is your team and can they handle the management and maintenance of the hardware and software of an additional data center?

VMC takes care of all of this

If moving to a Cloud Provider, does your team have the necessary skills to manage the workload and consume the services?

VMC requires no additional skill sets

Do you require the use of AWS services in your environment?

With VMC on AWS, you can deploy or migrate your VMs to the SDDC and consume the services without any egress costs. AWS service cost still applies.

How much would it cost to run your current Virtual Machine workload in VMC on AWS or a different Cloud Provider?

vRealize Business for Cloud provides you with cost comparisons between different Cloud Providers

vRBC also provides a VMC Assessment which provides a comparative analysis of utilization based cost on Private cloud vs. VMware Cloud on AWS. Sweet!

How do I take care of billing?

SDDC consumption will be billed through VMware. Fixed monthly costs which are great because it can be a roll of the dice using a Service Provider.

Your egress charges from SDDC Edge Gateways will be billed to VMware because the VPC is actually owned and managed by VMware as part of the service.

Any AWS related services will be billed to your AWS account.

If you make a decision on using a colo, then you have the following cost considerations:

Rack or Floor space / Power consumption

Compute

Storage

Licensing

Networking

ISP

Dark Fiber

Cabling

If you make a decision on using your own physical datacenter, then you have these cost considerations:

Compute

Storage

Licensing

Networking

ISP

Dark Fiber

Electricity

HVAC/Cooling

UPS Systems

Cabling

N+1 redundancy on physical infrastructure

This list can go on and on and on…

Now, let’s say you performed your due diligence and make the smart decision to purchase VMC on AWS. What’s next?

To sign up, please contact your partner or VMware account team.

After you receive your login for console access, you can start the onboarding process, which has some requirements and upfront considerations.

AWS requirements and decisions

You require an existing account on Amazon Web services, and if you do not have one, you can connect to a new AWS account.

The AWS account will be linked to your Cloud organization and as mentioned earlier and any AWS services consumed will be billed through this account.

The default VPC assigned subnet might conflict with your internal networks and create a problem when the VPC is linked to your SDDC. Please review your existing subnet and if necessary create a new non-conflicting subnet.

Make sure your subnet is in the same region as your planned SDDC

Subnet should have at least 64 IP addresses (/26) in each AZ in your VPC.

How many hosts do you need?

This will depend on your use case and workload requirements.

When you create the SDDC, you have the option to set your number of hosts, with a minimum of 4, which has a total capacity of 8 Sockets, 144 Cores, 2 TB RAM, 42.8 TB Storage.

Also, think about future growth and the maximum amount of hosts that you might deploy.

Cost considerations for your subscription

Select the number of hosts you want as part of the subscription and for what period (on-demand, 1 year, 3 years). Longer-term reservation of hosts gives you up to 50% cost saving!

Through the Hybrid Loyalty Program discount, you get an additional discount of up to 25% based on the number of eligible on-premises product licenses you own.

You have to make a decision on the Management IP address schemes that you want to use within your SDDC.

During the creation of your SDDC, you can configure the management subnet so make sure to pick a range that will not conflict with your existing on-premise networks as well as the AWS subnet that will connect to your SDDC.

Once the management network is created, it cannot be changed, and you would have to destroy your SDDC and start from scratch. Make an informed decision!

In which AWS region should your SDDC run in.

This will depend on your use case and current location.

At the time of writing US East (N. Virginia), US West (Oregon) and London (England) is available.

After the SDDC is created, you also have to make a decision on how you want to connect to your Management and Compute SDDC networks externally through the Edge Gateway. The following options are available.

IPsec VPN (L3)

This is available for both your management and compute network

L2VPN

This is only available for your compute network, and provides a secure communications tunnel between an on-premises network and one in your cloud SDDC.

Direct Connect

Service provided by AWS that allows you to create a high-speed, low latency connection between your on-premises data center and AWS services with no additional egress charges.

Either select a colo at AWS Direct Connect locations or will need APN Partners to establish network circuits between the AWS Direct Connect location and on-premises environment.

What ports do you require to be open on your Management and Compute network Firewall?

By default, your gateways are configured with a deny all policy.

The onboarding process is as follow:

Setup VMware Cloud Organization

Create an account by signing up

Log in to your Cloud console

Click on Invite users

Add users and pick their Organization role.

Set your theme, I like mine dark.

If you are a member of more than one Organization, set your default.

Create a subscription

This allows you to save money by committing to buy a certain amount of capacity for a defined period of time.

Choose wisely

Create your SDDC

Link your AWS account and choose your VPC and Subnet.

Choose the appropriate AWS region

Enter a name for your new SDDC

Select the number of hosts

Set a private subnet range for your management subnet

This will be used for vCenter Server, NSX Manager, and ESXi hosts.

Configure access to your Management cluster

This is required for access to the vCenter Server server as well as ESXi vMotion VMKernel network, for when you want to migrate your VMs into your VMC SDDC.

Configure the IPsec VPN

You need to decide if you want to use your existing physical networking gear for connectivity, or if you have NSX implemented you can use an Edge GW, or you can install a standalone Edge GW for free.

Routing

Don’t forget routing, your networking team would need to route your on-prem management network to this new network.

Firewall rules

Decide on what ports need to be opened for network connectivity to vCenter Server, NSX, ESXi remote console, vMotion, etc

DNS

Set DNS IP addresses to resolve computer names.

Configure access to your Compute cluster

Configure your logical networks

Need to decide what type of network you need, routed (default) or extended

Decide on an IP range and size of the subnet.

Routed network use the SDDC compute gateway as the default gateway, which means it has connectivity to other logical networks in the same SDDC, as well as to external networks like the Firewall and NAT.

Extended networks use an on-premises gateway as the default gateway and require L2VPN connectivity to be configured.

As a note, logical networks can be changed from routed to extended and extended to routed.

Routing

If you select a routed logical network, you need to decide which of your local compute networks you want to route for connectivity.

Firewall rules

Decide on what ports need to be opened for network connectivity to

This will probably require a bit more brain power because it will include all your workload application and however you decide where your workload will run. Knowing your mapped application dependencies is crucial and vRNI, as well as the Service discovery management pack for vROPS can help in understanding how your applications talk to each other and provide the necessary firewall rules that need to be created.

NAT

Do you need to connect public IP addresses directly to deployed VMs?

Public IP address

You need to decide if you require public IP address for maybe web front-end applications running in your SDDC. If so you need to request them and beware there are costs involved.

Configure Hybrid linked mode

Do you want to see both your onsite and VMC vCenter Server through a single pane of glass? This is a one-way connection so you always need to connect to your VMC on AWS vCenter Server to see both!

Definitely worth it and provides that live Cross-vCenter vMotion awesomeness.

Services

DRaaS

If your use-case is to protect your on-prem workload and recover them in your SDDC, you can activate Site Recovery.

The service consists of Site Recovery Manager (SRM) and vSphere Replication