The TAS for VMs [Windows] tile installs Windows Diego Cells in your Ops Manager deployment.
The TAS for VMs [Windows] tile inherits settings from the VMware Tanzu Application Service for VMs (TAS for VMs) tile and also includes additional configuration settings.
To install, configure, and deploy TAS for VMs [Windows]:
In an environment with internet access:
In an air-gap environment, complete the steps in Installing and configuring TAS for VMs [Windows] in an Air-Gapped Environment.
Before you install and configure the TAS for VMs [Windows] tile, ensure that you meet the requirements to use the Windows FS Injector tool. For more information, see Windows FS Injector Prerequisites.
You use the Windows FS Injector tool to install the TAS for VMs [Windows] tile. The Windows FS Injector tool requires:
tar executables must be in your
tar are not in your
%PATH%, either add your
tar executable locations to your existing
%PATH% configuration, or copy the
tar.exe executables to a directory in your
Your installation environment must allow the Windows FS Injector tool access to all of the following URLs:
Note To ensure the authenticity of Microsoft container images, Microsoft does not permit the distribution of its base images. This includes Microsoft container images consumed through Docker Hub, which are actually delivered by an Microsoft CDN endpoint.
To install the TAS for VMs [Windows] tile:
Go to the VMware Tanzu Application Service for VMs [Windows] page on VMware Tanzu Network.
Download the VMware Tanzu Application Service for VMs [Windows] product file.
Download the Windows FS Injector tool for your workstation OS. The Injector tool,
winfs-injector, is an executable binary file that adds the Windows Server container base image into the product file. This step requires Internet access and can take up to 20 minutes.
Important' You need the
tar executable files in your
%PATH% to run
winfs-injector.exe. For example, copy
tar.exe to a directory in your
Add the Windows Server container base image to the product file:
winfs-injector ^ --input-tile PASW-DOWNLOAD-PATH ^ --output-tile PASW-IMPORTABLE-PATH
PASW-DOWNLOAD-PATH is the path and filename to the TAS for VMs [Windows] product file you downloaded. *
PASW-IMPORTABLE-PATH is the desired output path for the importable product file.
C:\Users\admin\> winfs-injector ^ --input-tile c:\temp\pas-windows-2.9.0-build.1.pivotal ^ --output-tile c:\temp\pas-windows-2.9.0-build.1-INJECTED.pivotal
This step can take up to 20 minutes to complete.
Go to VMware Tanzu Operations Manager Installation Dashboard and click Import a Product.
To add the TAS for VMs [Windows] tile to the Import a Product product list, select the importable
PASW-IMPORTABLE-PATH file on your workstation.
To add the TAS for VMs [Windows] tile to your staging area, click + under the VMware Tanzu Application Service for VMs [Windows] product listing.
Assign jobs to your Availability Zones (AZs) and networks.
To configure AZs and networks:
Click the TAS for VMs [Windows] tile.
Select Assign AZs and Networks or Assign Networks. The name of the pane varies depending on your IaaS.
Select the first AZ under Place singleton jobs. Ops Manager runs any job with a single instance in this AZ.
Select all AZs under Balance other jobs. Ops Manager balances instances of jobs with more than one instance across the AZs that you specify.
For production deployments, VMware recommends at least three AZs for a highly available installation.
From the Network drop-down menu, choose the runtime network that you created when configuring the BOSH Director tile.
In VM Options, you configure settings for accessing your VMs.
To configure VM access:
Select VM Options.
Select one of the following for Manage administrator password:
(Optional) To start the Microsoft beta port of the OpenSSH daemon on port 22 on all VMs, select the Enable BOSH-native SSH support on all VMs (beta) check box. If you select this option, users can SSH into Windows VMs with the
bosh ssh command and enter a CMD terminal as an admin user. They can then run
powershell.exe to start a PowerShell session.
(Optional) To configure a Key Management Service (KMS) that your volume-licensed Windows Diego Cell can register with:
In Smoke Tests, you specify the org and space where smoke tests are run.
In the org and space that you specify, the Smoke Test errand pushes an app to the org. The app runs basic functionality tests against your TAS for VMs [Windows] deployment after an installation or update.
The Smoke Test errand is on by default. You can turn off the Smoke Test errand in the Errands pane. For more information, see Configure Errands.
To configure smoke tests:
Select Smoke Tests.
If you have a shared apps domain, select A temporary space within the system org, which creates a temporary space within the system org for running smoke tests and deletes the space afterwards. Otherwise, select A specified org and space and complete these fields to configure where TAS for VMs [Windows] pushes an app to run smoke tests:
Advanced Features includes new functionality that might have certain constraints. Although these features are fully supported, VMware recommends caution when using them in production environments.
The following sections describe how to configure the advanced features.
For example, you might want to use the overcommit if your apps use a small amount of disk and memory capacity compared to the amounts set in the Resource Config settings for Windows Diego Cell.
Note Due to the risk of app failure and the deployment-specific nature of disk and memory use, VMware has no recommendation for how much, if any, memory or disk space to overcommit.
To enable overcommit:
Select Advanced Features.
Enter in MB the total desired amount of Diego Cell memory in the Diego Cell memory capacity field. See the Diego Cell row in Resource Config for the current Diego Cell memory capacity settings that this field overrides.
Enter in MB the total desired amount of Diego Cell disk capacity in the Diego Cell disk capacity field. See the Diego Cell row in Resource Config for the current Diego Cell disk capacity settings that this field overrides.
Important Entries made to each of these two fields set the total amount of resources allocated, not the overage.
You can choose the method the Gorouter uses to verify app identity. Verifying app identity using TLS or mutual TLS (mTLS) enables encryption between the Gorouter and app containers and guards against misrouting during control plane failures. This feature is deactivated by default.
For more information about Gorouter route consistency modes, see Preventing Misrouting in HTTP Routing.
To configure app identity verification:
Select Advanced Features.
Under TLS connections from the Gorouter to apps (beta), select one of the following options:
Errands are scripts that Ops Manager runs automatically when it installs or uninstalls a product, such as a new version of TAS for VMs [Windows]. There are two types of errands: post-deploy errands run after the product is installed, and pre-delete errands run before the product in uninstalled.
By default, Ops Manager runs all errands.
In Errands, you can change these run rules. For each errand, you can select On to run it each time Ops Manager installs or uninstalls a product, or Off to never run it.
For more information about how Ops Manager manages errands, see Managing Errands in Ops Manager.
To configure errands:
To ensure that you receive the most up-to-date HWC buildpack, set the Install HWC Buildpack Errand to On.
To ensure that a smoke test is run against your TAS for VMs [Windows] installation, set the Smoke Test Errand to On.
Important This beta feature checks only that the client certificate is signed by the expected CA using mTLS. It does not include SAN (Subject Alternative Name) checks of the presented client certificates.
To deploy your TAS for VMs [Windows] app workloads to an isolation segment, select App Containers and follow the procedure in Assign a Tile to an Isolation Segment in Windows Diego Cells in Isolation Segments.
To configure Windows Diego Cells to send vm logs to an external syslog server, select System Logging and follow the procedure in Forwarding Logs to a Syslog Server in Troubleshooting Windows Diego Cells.
To configure DNS search domains for your app containers:
In Resource Config, you must associate load balancers with the VMs in your deployment to enable traffic.
To configure your tile resources:
Select Resource Config.
Use the drop-down menus to configure Windows Diego Cell. The following table shows the recommended Windows Diego Cell disk size for your IaaS:
|IaaS||Recommended Windows Diego Cell Disk Size|
Note Windows stemcells in the v2019.x line support ephemeral disks.
Provision your Master Compilation Job with at least 100 GB of disk space.
After configuring resources for the TAS for VMs [Windows] tile, you must upload the Windows stemcell to the tile.
To upload the stemcell:
In the TAS for VMs [Windows] tile, select Stemcell Library.
Retrieve the stemcell that you downloaded or created in Downloading or Creating a Windows Stemcell.
Follow the procedure in Importing and Managing Stemcells to upload the Windows stemcell to TAS for VMs [Windows].
Note If you use vSphere, you must create your own stemcell. The default root disk size of Windows stemcells v2019.x line is 30 GB. VMware recommends setting the root disk size of your Windows stemcell for vSphere to 30 GB. For more information, see Creating a Windows Stemcell for vSphere Using stembuild.
After you upload the Windows stemcell to the TAS for VMs [Windows] tile, you are ready to deploy the tile.
To deploy the TAS for VMs [Windows] tile:
Go to the Ops Manager Installation Dashboard.
Click Review Pending Changes.
Select the TAS for VMs [Windows] tile and review the changes. For more information, see Reviewing Pending Product Changes.
Click Apply Changes.
To run Windows Diego Cells in multiple isolation segments, you must create and configure additional TAS for VMs [Windows] tiles. For more information, see Windows Diego Cells in Isolation Segments.
To install, configure, and deploy TAS for VMs [Windows] in an air-gapped environment:
Follow the steps in Preparing a Windows Rootfs Image in a Private Registry.
Follow the steps in Install the Tile with the following exceptions:
winfs-injectorcommand line with the
winfs-injectorprocedure in Adding the Windows Server Container Base image to the product file.
To create a TAS for VMs [Windows] tile, a windows file-system container image is typically fetched from a Docker registry. An administrator can fetch the windows file-system image from either cloudfoundry/windows2016fs the publicly hosted DockerHub repository, or a privately hosted container image registry.
To prepare a windows file-system container image in a private registry:
To download the windows file-system container image, run the following command:
docker pull cloudfoundry/windows2016fs:2019
To tag the Windows container image, run the following command:
docker tag cloudfoundry/windows2016fs:2019 REGISTRY-ROOT/cloudfoundry/windows2016fs:2019
REGISTRY-ROOT is your private registry’s URI.
To upload the Windows Container image to your accessible private registry, run the following command:
docker push IMAGE-URI
IMAGE-URI is the URI to the Windows rootfs image in your private registry. Your image URI should follow the pattern:
To add the Windows Server container base image to the product file in an air-gapped environment, run the following:
winfs-injector ^ --input-tile PASW-DOWNLOAD-PATH ^ --output-tile PASW-IMPORTABLE-PATH ^ --registry PASW-REGISTRY-URI
PASW-DOWNLOAD-PATHis the path and filename to the PASW product file you downloaded.
PASW-IMPORTABLE-PATHis the desired output path for the importable product file.
PASW-REGISTRY-URIis the uri to the container registry hosting your cloudfoundry/windows2016fs image.
C:\Users\admin> winfs-injector ^ --input-tile c:\temp\pas-windows-2.6.0-build.1.pivotal ^ --output-tile c:\temp\pas-windows-2.6.0-build.1-INJECTED.pivotal ^ --registry https://my.registry.com
For information about troubleshooting
winfs-injector, see Missing Local Certificates for Windows File System Injector in Troubleshooting Windows Diego Cells.