Configuring VMware Cross-vCenter NSX

This post provides an overview of cross-vCenter NSX and walks through the configuration steps. Cross-vCenter NSX allows central management of network virtualization and security policies across multiple vCenter Server systems. Cross vCenter NSX introduces universal objects; such as universal logical switches, universal logical routers, and universal distributed firewall rules. Universal objects are able to span multiple sites or vCenter Server instances, enhancing workload mobility by allowing cross vCenter and long distance vMotion for virtual machines, whilst keeping the same network settings and firewall rules. This improves DR capabilities, overcomes scale limits of vCenter Server, and gives administrators more control over resource pooling and the separation of environments.

Cross vCenter-NSX was introduced in NSX v6.2 and requires vSphere v6.0 or later. As normal NSX Manager is deployed with vCenter server in a 1:1 pairing.  In a single site NSX deployment the NSX Manager is given the standalone role by default. When configuring cross-vCenter NSX one NSX Manager is assigned the primary role, and up to seven other NSX Managers are assigned the secondary role. NSX Managers configured for cross-vCenter NSX must all be running the same version. The primary NSX Manager is responsible for deploying the Universal Controller Cluster; forming the control plane across the NSX Managers. The Universal Controller Cluster runs in the site of the primary NSX Manager. Universal objects are created on the primary NSX Manager and automatically synchronized across the multi-site NSX environment.

Configuring Cross-vCenter NSX

The steps below assume you have already deployed and registered the NSX Managers, and have a good understanding of NSX. This post is intended as add on to the NSX Install Guide to provide an outline of the additional or different steps required for a cross-vCenter NSX install, further resources are listed at the bottom of the page. If you are using vCenter enhanced linked mode then multiple NSX Manager instances are displayed within the same interface, or single pane of glass, when managing the Network & Security section of the vSphere web client. Enhanced linked mode is not a requirement for cross-vCenter NSX however, and vCenter Server systems not in enhanced linked mode can still be configured for cross-vCenter NSX.

From the Networking & Security page of the vSphere web client select Installation, highlight the NSX Manager in the primary site, from the Actions menu select Assign Primary Role.

NSX_Promote

The secondary NSX Manager(s) synchronize with the primary using the Universal Synchronization Service. These sites do not run any NSX Controllers, although they can be redeployed easily in the event of a primary site outage. Before assigning the secondary role you should ensure there are no existing NSX Controllers deployed in the associated vCenter. If you have already assigned a segment ID pool to the NSX Managers then ensure the segment ID pools do not overlap. Select the primary NSX Manager and from the Actions menu click Add Secondary NSX Manager. Enter the secondary NSX Manager information and admin password.

NSX2

Review the table of NSX Managers, the roles have now changed accordingly.

NSX_Roles

The universal controller cluster is formed by individually deploying the NSX controllers from the primary NSX Manager, the method of deploying the controllers is the same (see NSX Install Guide Part 1 – Mgmt and Control Planes for further assistance). Once the controllers are deployed you will notice placeholder controllers listed against the secondary NSX Manager, these are not connected or deployed. In the event of a site failure the configuration is synchronized between NSX Managers so you can simply re-deploy the controllers in the DR site. To see the failover process review this blog post. VMware recommend deploying 3 controllers on different hosts with anti-affinity rules.

NSX_Controllers

The next part of the install process is to follow the host preparation and VXLAN configuration steps as normal (see NSX Install Guide Part 2 – Data Plane for further assistance). Create the segment ID pools for each NSX Manager, making sure they do not overlap. On the primary NSX Manager you will also assign a universal segment ID pool.

In order for us to deploy universal logical switches we need to create a universal transport zone. A universal transport zone determines which hosts a universal logical switch can reach, spanning multiple vCenters. From the Logical Network Preparation tab open Transport Zones, ensure the primary NSX Manager is selected and click the plus symbol. Select Mark this object for Universal Synchronization, and enter the configuration for the universal transport zone. All universal objects must be created on the primary NSX Manager, change the NSX Manager to the secondary site and you will see the universal transport zone has synchronized there also.

NSX_TZ

Next we will create a universal logical switch for the transit network. Local objects such as logical switches, logical routers, and Edge Services Gateways can still be deployed from each NSX Manager, although by design they are only local to the vCenter linked to that specific NSX Manager, and cannot be deployed or edited elsewhere. From the left hand navigation pane in Networking & Security select Logical Switches, ensure the primary NSX Manager is selected and click the plus symbol. Enter a name for the transit network and select the universal transport zone we created earlier.

NSX_Universal_Transit

At this stage you can also deploy another universal logical switch, connecting a couple of test VMs on a private subnet, and have them ping one another to confirm connectivity. Now that we have a transit network and test universal logical switches connected to our universal transport zone we can go ahead and create a universal DLR. In this particular environment we have already deployed an ESG in each site. For further assistance with deploying an ESG and DLR see NSX Install Guide Part 3 – Edge and DLR.

From the Networking & Security page click NSX Edges, ensure the primary NSX Manager is selected and click the plus symbol. The control VM for the DLR is deployed to the primary site, again the configuration is synchronized and this can be re-deployed to the DR site in the event of a primary site outage. Select Universal Logical Router and follow the wizard as normal, if local egress is required then check the appropriate box. Sites configured in a cross-vCenter NSX environment can use the same physical routers for egress traffic, or have the local egress feature enabled within a universal logical router. The local egress feature allows routes to be customized at host, cluster, or router level.

NSX_UDLR

From the NSX Edges page double click the new universal DLR, select Manage, Settings, Interfaces and click the add button. In order for traffic to route from the universal DLR to the ESG(s) we must add an uplink interface connecting them to the universal transit network. Change the logical router interface to Uplink, in the Connected To field select the transit network universal logical switch we created earlier. Configure the IP and MTU settings of the interface per your own environment.

NSX_UDLR_Interface

You can also add Internal interfaces here corresponding with universal logical switches for virtual machine subnets. Before these subnets can route out follow the same process to add an Internal interface to the ESG(s) connecting them to the same transit network.

A virtual machine connected to the test universal logical switch can now vMotion between sites keeping the same IP addressing, providing L2 over L3 capability. As well as remaining on the same logical network a virtual machine can also be migrated across sites without any additional firewall rules, this is achieved with the use of universal firewall rules. Universal firewall rules require a dedicated section creating under the Firewall section of Networking & Security, you must select Mark this section for Universal Synchronization. For assistance with creating universal firewall rules see here.

NSX_Universal_Firewall

Additional Resources

To plan a cross-vCenter NSX installation review the VMware Cross-vCenter NSX Design Guide, Cross-vCenter NSX Topologies Guide, and the VMware Cross-vCenter Installation Guide. For more information on cross-vCenter NSX design see the following blog posts:

Installing vCenter Internal CA signed SSL Certificates

This post will walk through the process of replacing the default self-signed certificates in vCenter with SSL certificates signed by your own internal Certificate Authority (CA). In previous versions of vSphere the certificate replacement procedure was so complex that many administrators ignored it completely. Now with the certificate tool improvements in vSphere 6.x, and the ever increasing security threat of todays digital world, applying SSL certificates takes on an enhanced significance for verifying servers, solutions, and users are who they say they are.

The procedure outlined below is specific to installing Microsoft intermediate CA signed certificates on VCSA 6.5 with embedded PSC, protecting us against man in the middle attacks with a secure connection which we can see in the screenshot below. From v6.0 onwards the VMware Certificate Authority (VMCA) was also introduced, for more information on using the VMCA see this blog post, or to read how to use the VMCA as an intermediate CA see here. VMware documentation for replacing self-signed certificates can be reviewed from this KB article.

Trusted_vSphere

Before beginning the replacement certificate process ensure you have a good backup, and snapshot of the VCSA. The following links are the official VMware guides and this blog post provides a good overview of the certificates we’re actually going to be replacing. Replacing default certificates with CA signed SSL certificates in vSphere 6.x (2111219)Replacing a vSphere 6.x Machine SSL certificate with a Custom Certificate Authority Signed Certificate (2112277)How to replace the vSphere 6.x Solution User certs with CA signed certs (2112278).

Generate CSR

The first thing we need to do is generate a Certificate Signing Request (CSR). Open an SSH connection to the VCSA using an SSH client such as Putty, and login as root – if you need to enable SSH you can do so from the VAMI (https://vCenterIPorFQDN:5480) under Access; enable both SSH Login and Bash Shell. Run the following command to open the VMware built in Certificate Manager tool:

/usr/lib/vmware-vmca/bin/certificate-manager

Cert_Tool_1

Select the appropriate option. In this case we first want to replace the machine SSL certificate with a custom certificate, option 1. When prompted enter the SSO administrator username and password. Enter 1 again to generate certificate signing request(s) and Key(s) for machine SSL certificate, and enter the output directory. In the example below we are using the /tmp directory. Fill in the required values for the certool.cfg file.

Cert_Tool_2

The CSR and key are generated in the location specified. Change the shell to /bin/bash using chsh -s "/bin/bash" root and open an SCP connection to the VCSA using WinSCP. Copy the vmca_issued_csr.csr file to your local machine, you can use Notepad to view the contents of the file. Leave the WinSCP session open as we’ll need it to copy the certificate chain back to the VCSA.

Request Certificate

The next step is to use the CSR to request a certificate from your internal Certificate Authority (official KB here). A Microsoft CA template needs creating with the settings specified here (official KB here) before requesting the certs. Once this is done open a web browser to the Microsoft Certificate Services page (normally https://CAServer/certsrv) and select Request a Certificate.

Internal_CA_1

Then we want to Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file. The next page allows us to enter the CSR generated earlier to request a certificate with the pre-configured vSphere 6.5 certificate template.

Internal_CA_2

Click Submit and then select Base 64 encoded and Download certificate and Download certificate chain. A .cer file will be downloaded, I have renamed this machine_name_ssl.cer, and a .p7b. Double click the .p7b file to open in certmgr, locate and right click the root certificate, select All Tasks, Export. Export the root certificate in Base-64 encoded X.509 (.CER) format, in this example I have named the file Root64.cer. Using WinSCP copy the machine and root certificate files to the VCSA.

Install Certificate

Go back to Certificate Manager and enter 1 to continue to importing custom certificate(s) and key(s) for machine SSL certificate. Enter the file for the machine SSL certificate we copied, I have used /tmp/machine_name_ssl.cer. Enter the associated custom key that was generated with the CSR request, in this case /tmp/vmca_issued_key.key. Finally, enter the signing certificate of the machine SSL certificate, in this case /tmp/Root64.cer. When prompted enter y to replace the default machine SSL certificate with the custom certificate.

Cert_Tool_3

The certificate will now be installed, when finished a success message will be displayed. If certificate installation fails at 0% see this KB article.

Cert_Tool_4

To verify the machine certificate open a web browser to the vCenter FQDN, the connection will now show secure. Depending on the browser used you can view the certificate properties to verify it is correct, alternatively browse to https://vCenterFQDN/psc and log in with an SSO administrator account. Open Certificate Management and Machine Certificates, select the installed machine certificate and click Show Details, verify the certificate properties are correct.

Certificate_Management

Solution User Certificates

Repeat the steps above for the solution user certificates (official KB here). Replacing the solution user certificates may break some external plugins, such as SRM, in which case you should review this KB article for corrective action. To recap: /usr/lib/vmware-vmca/bin/certificate-manager. This time select option 5 replace solution user certificates with custom certificates. Generate the CSRs and keys, you will notice that for the solution user certs 4 CSR and key files are created; machine, vsphere-webclient, vpxd, and vpxd-extension.

Cert_Tool_5

Using WinSCP copy the files to your local machine and repeat the certificate request process from the Microsoft Certificate Services page. Copy the new certificates to the VCSA and repeat the install process. Solution User certificates can be viewed on the PSC web interface under Certificate Management, Solution User Certificates.

Solution_User_Management

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

Reconfiguring vCenter Server for External PSC

An external Platform Services Controller (PSC) can provide scalability and high availability across sites. A vCenter Server initially deployed with an embedded PSC can be reconfigured to use an external PSC by following the steps outlined below. Multiple external Platform Services Controllers can be deployed and an environment can be mixed between the appliance and Windows versions of vCenter Server and PSC.

externalpsc

Considerations

  • The vCenter Server must be running at least version 6.0 Update 1.
  • The process involves the installation of an external PSC as a new target for vCenter Server. The PSC must be in the same Single Sign-On site and domain as the vCenter Server.
  • Ensure you have good backups of your vCenter Server. If the vCenter Server is virtual take a snapshot before starting the process, likewise after deploying the new PSC take a snapshot.
  • If the process fails for any reason revert back to the snapshots.
  • An external PSC deployment model cannot be converted into an embedded PSC.
  • If vCenter HA is enabled then disable and reconfigure after the process is complete. For more information see Configuring vCenter 6.5 High Availability.
  • The commands outlined below are the same for the vCenter Server Appliance and Windows vCenter Server, unless specified. Take into account the following environmental variables:
    • For Windows all commands should be run as an administrator in an elevated command prompt.
    • For the appliance use the root account for all commands, enable BASH and launch the shell by running shell.set -enabled True followed by shell.

Process

The first step is to determine the Single Sign-On site by running the following commands on the vCenter Server: vCenter Server Appliance: /usr/lib/vmware-vmafd/bin/vmafd-cli get-site-name --server-name localhost. Windows vCenter Server: "C:\Program Files\VMware\vCenter Server\vmafdd\vmafd-cli" get-site-name --server-name localhost.

Make a note of the SSO site. Next deploy the new external Platform Services Controller, if you require assistance with this see the Deploying an External Platform Services Controller post. The new PSC must be configured with the same Single Sign-On site and domain as the vCenter Server you want to reconfigure.

joindomain

joinsite

Once the external PSC is up and running go back to the vCenter Server. Confirm the Platform Services Controller services are running, for Windows first navigate to the correct directory by using:

cd "C:\Program Files\VMware\vCenter Server\bin".

For both the appliance and Windows versions run the following command:

service-control --status --all

Check that the VMware License Service, VMware Identity Management Service, VMware Security Token Service, VMware Certificate Service, and VMware Directory Services are running.

cmd

To reconfigure the vCenter Server to use the new PSC use the following command, replacing newpsc with the IP or FQDN (case sensitive) of the new PSC, username, domainname, and password with the relevant SSO domain and user details.

cmsso-util reconfigure --repoint-psc newpsc --username username --domain-name domainname --passwd password

If the external PSC is configured to use a custom port then add [--dc-port port] where port is the port number. Check the configuration results.

results

Confirm the vCenter is accessible by logging in to the vSphere web client. The process is complete, if you disabled vCenter HA then you can now go ahead and reconfigure.

Deploying an External Platform Services Controller

This post will walk through the process of deploying an external Platform Services Controller (PSC) appliance. The PSC was introduced with vSphere 6.0 to deal with infrastructure services such as Single Sign-On, Certificate Authority, and licensing.  For more information on the Platform Services Controller review this KB.

The PSC can be either embedded within the vCenter Server, or external to allow scale out for larger environments. When deciding if an embedded or external PSC is appropriate review the vCenter Server deployment models here. The external PSC can be installed as a virtual appliance, or installed on a Windows server (virtual or physical). Environments can be mixed, for example a PSC virtual appliance can be deployed where a physical Windows vCenter currently exists. You may also want to review the following posts:

Installation Process

Downloaded the VMware vCenter Server Appliance here: v6.0, v6.5.

Mount the ISO on your computer. The VCSA 6.5 installer is compatible with Mac, Linux, and Windows. Browse to the corresponding directory for your operating system, e.g. \vcsa-ui-installer\win32. Right click Installer and select Run as administrator. As we are installing a new instance click Install.

psc1

On the welcome page click Next. Accept the license agreement and click Next.

psc3

For the deployment type we need to select Platform Services Controller under the External Platform Services Controller heading. Click Next.

psc4

Enter details of the vCenter or ESXi host where the appliance will be deployed, click Next.

psc5

Select a location for the virtual appliance and click Next.

psc6

Select the compute resource for the virtual appliance and click Next.

psc7

Enter a name for the virtual appliance and configure the root password, click Next.

psc8

Select the storage to use and click Next.

psc9

Select the VM network to use and configure the network settings, click Next.

psc10

Review the deploy Platform Services Controller summary page and click Finish. The Platform Services Controller appliance will now be deployed.

stage2

In stage 2 we configure the new appliance, click Next.

config

Configure the NTP server(s) and click Next.

config1

The SSO configuration page is where we determine if the PSC should be joined to an existing SSO domain or if you are creating a new SSO domain. Enter the SSO domain details and click Next.

config2

Tick or untick the Customer Experience Improvement Program and click Next.

config3

On the summary page click Finish and Ok. The PSC virtual appliance will now be configured.

config4

Once complete we can access the Platform Services Controller in 2 different ways. For the appliance management portal browse to https://IP:5480 where IP is the IP or FQDN of the virtual appliance. Login with the root account.

root

Here we can configure settings specific to the virtual appliance, such as networking, SSH, syslog, etc.

root2

To access the user interface browse to https://IP/psc where IP is the IP or FQDN of the virtual appliance. Login with the administrator@vsphere.local account created or defined in the installation wizard.

psc

Here we can configure Platform Services Controller related settings, such as permissions, certificates, etc. To join the PSC to an Active Directory domain browse to Appliance Settings, and Manage. Under Active Directory click Join.

domain

The Platform Services Controller has now been deployed and configured. Multiple PSC instances can be placed behind a load balancer to provide High Availability, as outlined in this KB.

vSphere 6.5 Content Libraries

I was aware of Content Libraries when the feature was released in vSphere 6.0, although I didn’t make use of it. I found this article by Jon Kensy which gives a really good review on the usability of Content Libraries in vSphere 6.0, however there have been improvements since then. In this post we’ll take a look at Content Libraries in vSphere 6.5, which has additional features including the option to mount an ISO from a Content Library, update existing templates, and apply guest OS Customisation Specifications during VM deployments. If Content Libraries reside on VCSA then we can also make use of vCenter HA, and native Backup and Restore, both new to v6.5.

In the steps below we will create a publisher library, add some content, and then create a subscription library on a different vCenter Server. You can learn more about Content Libraries in the vSphere 6.5 Documentation Centre.

contentlibrary

Create Publisher Library

The vCenter Server where the Content Library will be updated is assigned the publisher role. Log into the vSphere web client of the vCenter Server to deploy the publisher library, from the home page select Content Libraries.

contentlibrary1

From the Objects tab click the icon with the green plus symbol to create a new library. The new library wizard will open. Enter a name, and description if required. Select the vCenter Server to be the publisher and click Next.

contentlibrary2

Select Local content library. To allow other vCenter Servers to subscribe select Publish content library externally (this can be done later if required). If you want to add a password to the library tick Enable authentication. Click Next to continue.

contentlibrary3

Select the storage where the library will reside, click Next.

contentlibrary4

Review the details on the summary page and click Finish. The Content Library has been created.

contentlibrary5

Add Content

With the new Content Library selected, browse the different tabs. Configure allows us to publish the library for other vCenter Servers, and password protect if required. The subscription URL is also listed, which is needed to add a subscription library on a different vCenter Server.

The Templates tab is self explanatory and lists the templates stored in the Content Library. Templates can be imported or created from an existing virtual machine or template in the inventory. To create a template from a virtual machine right click and select Clone, Clone to Template in Library.

clone

A new template will be created. For existing templates you can right click and choose Clone to Library.

existingtemplate

Now from the Content Library we can right click the template and select New VM from This Template. The usual deploy virtual machine from template wizard opens, here we also have the option to customise the guest OS with a Customisation Specification.

template

Using the Other Types tab files such as ISO or OVA can be added. Once an ISO is imported it can be mounted to a virtual machine direct from the Content Library.

iso

Create Subscription Library

Additional vCenter Servers which will pull content from the publisher are assigned the subscription role. Log into the vSphere web client of the vCenter Server to subscribe to the library, from the home page select Content Libraries.

contentlibrary1

From the Objects tab click the icon with the green plus symbol to create a new library. The new library wizard will open. Enter a name, and description if required. Select the vCenter Server to be the subscriber and click Next.

contentlibrary2

Select Subscribed content library. Enter the Subscription URL provided by the publisher library. If authentication is required then select the appropriate tick box. You should also decide whether to download all the content now, or download on demand. Obviously the latter will use less storage capacity however access to library items will be slower. When you’re ready click Next.

subscription

Select the storage where the library will reside, click Next.

storage

Review the details on the summary page and click Finish. The Content Library has been added. From the drop-down Actions menu you can manually synchronise the library, edit, rename, or delete.