VMware Cloud on AWS Demo

This opening post will give an overview and demo of VMware Cloud on AWS. VMware Cloud on AWS provides on-demand, scalable cloud environments based on existing vSphere Software-Defined Data Center (SDDC) products. VMware and AWS have worked together to optimise running vSphere, vSAN and NSX, directly on dedicated, elastic, bare-metal AWS infrastructure without the need for nested virtualization. A SDDC cloud can be deployed in a few hours and then capacity scaled up and down within minutes.

Key Benefits

There are a number of benefits and use cases for extending on-premise data centers to the cloud with VMware Cloud on AWS:

  • VMware maintains software updates, emergency software patches, and auto-remediation of hardware failures
  • Increasing capacity in the cloud is generally quicker, easier, and sometimes more cost effective than increasing physical capacity in the data center
  • Scale capacity to protect services when met with temporary or unplanned demand
  • Improve business continuity by using the cloud for Disaster Recovery (DR) with VMware Site Recovery
  • Consistent operating environments allows for simplified cloud migrations with minimal re-training for system administrators
  • Transfer your existing operating system and third party licensing to the cloud and make use of existing support contracts with VMware
  • Expand footprint into additional geographical locations without needing to provision new data centers

Key Details

The following links contain enough reading to plan your VMware Cloud on AWS implementation and cloud migration strategy, the points below should be enough to get you started.

VMware Cloud on AWS: Product Documentation | Technical Overview | VMware Product Page | VMware FAQ| AWS Product Page | AWS FAQRoadmap | Case Study

Try first @ VMware Cloud on AWS – Getting Started Hands-on Lab

  • Each SDDC supports 4 to 32 hosts, each with 512 GB of memory and 2.3 GHz CPUs (custom-built Intel Xeon Processor E5-2686 v4 CPU package) with 18 cores per socket for a total of 36 cores
  • Each SDDC cluster uses an all-flash vSAN configuration utilising NVMe storage
  • An initial 4 host cluster provides roughly 21 TB usable capacity
  • Each ESXi host is connected to an Amazon Virtual Private Cloud (VPC) through Elastic Networking Adapter (ENA), which supports throughput up to 25 Gbps
  • Hybrid Cloud Extension allows stretched subnets between on-premise and cloud data centers for live migration of virtual machines
  • Hybrid Linked Mode allows administrators to connect vCenter Server running in VMware Cloud on AWS to an on-premises vCenter server to view both cloud and on-premises resources from a single interface
  • VMware Cloud on AWS complies with ISO 27001, ISO 27017, ISO 27018, SOC 1, SOC 2, SOC 3, HIPAA, and GDPR
  • VMware Cloud on AWS is managed from a web-based console or RESTful API
  • At the time of writing VMware Cloud on AWS is available in the AWS Europe (Frankfurt and London), AWS US East (N. Virginia) and AWS US West (Oregon) Regions
  • Basic pricing before discount can be calculated here

VMware_AWS

Product Demo

The demo below creates a SDDC in the cloud for lab purposes. Before deploying your own environment you should review all the above linked documentation and do your own research to plan your cloud strategy as well as the following:

  • Identify or create an AWS account and ensure that all technical personnel have access to the account
  • Identify a VPC and subnet by cross-linking the AWS account to the SDDC
  • Allocate IP ranges for the SDDC, and determine a DNS strategy
  • Identify the authentication model for the SDDC
  • Plan connectivity to the SDDC
  • Develop a network security policy for the SDDC

Browse to the VMware Cloud Services portal (https://console.cloud.vmware.com) and login using your VMware ID. At the time of writing to access VMware Cloud on AWS you need to be invited or you can register for a 30 day single host trial here.

VMware_Cloud

Select VMware Cloud on AWS. If you have not used the service before you will be prompted to create a new organisation. Enter a name for your new organisation and accept the terms of service, click Continue.

AWS_1

Add a credit card to be billed if you use the service. If you are using one of the free or trial methods outlined above you will not be billed.

aws_2.png

After you have created the organisation and added payment information you will be sent to the VMware Cloud on AWS dashboard. The first step is to create our SDDC in the cloud, click Create SDDC.

Billing: annual subscriptions are listed under the Subscriptions tab, you can see other billing information from the drop-down menu next to your organisation name: select Organisation Settings, View Organisation. From here you have services, identity and access management, billing and subscriptions, and support options.

AWS_3

Select a region and deployment model for the SDDC, enter a name and the number of hosts if you are not using the single host deployment. Click Next.

AWS_4

Follow the instructions to connect an AWS account and assign the relevant capabilities.

AWS_5

Once the connection is successfully established click Next.

AWS_7

Select the VPC and subnet to use then click Next.

AWS_8

Specify a private subnet range for the management subnet or leave blank to use default addressing. As mentioned above ensure you have planned accordingly and are not using any ranges that will conflict with other networks you may connect in the future. Click Deploy SDDC.

AWS_9

The SDDC will now be deployed, it takes around 2 hours to provision the ESXi hosts and all management components.

AWS_10

Once the deployment is complete the dashboard will show the new SDDC and assigned resources. Click View Details (you can toggle the web portal theme using the Dark/Light options in the top right hand corner).

AWS_14

From either the SDDC Summary tab or back on the SDDC dashboard you can seamlessly add additional hosts or clusters at any time.

AWS_15

If needed the chat bubble in the bottom right hand corner of the screen will take you through to support.

AWS_Support

The Network tab shows the network topology and is where you can configure firewall rules, NAT rules, VPN, Direct Connect, etc.

AWS_12

To access the vCenter Server through the vSphere client the port needs opening, a VPN can also be used. Under Management Gateway select Firewall Rules, click Add Rule. Configure the rule to allow access to the vCenter on port 443 and click Save.

AWS_11

Click Open vCenter from either the Summary or Network tab, if access is in place you are given the cloudadmin@vmc.local credentials to open vCenter. Active Directory can also be configured as an identity source later on.

Once you are logged into the vSphere client you will see the familiar vSphere layout.

vCenter_AWS

It is also possible to see your on-premise vCenter Server(s) in the same pane of glass using Hybrid Linked Mode, click here for more information.

Back in the VMware Cloud on AWS portal the Add Ons tab features Site Recovery and Hybrid Cloud Extension for protecting and migrating workloads to your SDDC in the cloud.

AWS_16

You can delete a SDDC from the Actions drop-down menu in either the SDDC Summary tab or the SDDC dashboard. Once a SDDC is deleted all workloads, data, and interfaces are destroyed and any public IP addresses released.

AWS_17

VMware vSAN 6.7 Install Guide

esxsi.com

VMware vSAN utilises server attached flash devices and local hard disk drives to create a shared datastore across hosts in a vSphere cluster. VMware vSAN achieves high availability by adding a software layer leveraging existing server hardware to provide the same resiliency and features as expensive SAN, NAS, or DAS arrays. Further to this vSAN is uniquely embedded within the hypervisor kernel, directly in the I/O path allowing it to make rapid data placement decisions without the installation of additional VIBs or virtual appliances. This post intends to give an overview of vSAN 6.5/6.7 and how to enable it.

VSAN

For further reading visit the VMware Documentation Centre and expand vSAN under the relevant version.

View original post 1,077 more words

Migrating Windows vCenter Server to VCSA 6.7

VMware vCenter Server pools ESXi host resources to provide a rich feature set delivering high availability and fault tolerance to virtual machines. The vCenter Server is a centralised management application and can be deployed as a virtual appliance or Windows machine. It should be noted that vCenter 6.7 is the final release where Windows modules will be available, see here for more information. All future releases will only be available as vCenter Server Appliance (VCSA) which is the preferred deployment method of vCenter Server. This post gives a walk through on migrating from a Windows based vCenter Server (VCS) to the Photon OS based vCenter Server Appliance (VCSA).

vCenter 6.7: Download | Release Notes | What’s New | VMware DocsvSphere Central

About VCSA

migrate2vcsaThe VCSA is a pre-configured virtual appliance built on Project Photon OS. Since the OS has been developed by VMware it benefits from enhanced performance and boot times over the previous Linux based appliance. Furthermore the embedded vPostgres database means VMware have full control of the software stack, resulting in significant optimisation for vSphere environments and quicker release of security patches and bug fixes. The VCSA scales up to 2000 hosts and 35,000 virtual machines. A couple of releases ago the VCSA reached feature parity with its Windows counterpart, and is now the preferred deployment method for vCenter Server. Features such as Update Manager are bundled into the VCSA, as well as file based backup and restore, and vCenter High Availability. The appliance also saves operating system license costs and is quicker and easier to deploy and patch.

Migrating to VCSA involves the deployment of a new appliance and migration of all configuration (including distributed switches) and historical data using the upgrade installer. The VCSA uses a temporary IP address during migration before switching to the IP and host name of the VCS, the Windows box is then powered off.

Software Considerations

  • The Windows VCS must be v.6.0 or v6.5 (any build / patch) to migrate to VCSA 6.7. Both physical and virtual vCenter Server installations are compatible.
  • Any database, internal or external, supported by VCS can be migrated to the embedded vPostgres database within the target VCSA.
  • The ESXi host or vCenter where VCSA will be deployed must be running v5.5 or above. However, all hosts you intend to connect to vCenter Server 6.7 should be running ESXi 6.0 or above, hosts running 5.5 and earlier cannot be managed by vCenter 6.7 and do not have a direct upgrade path to 6.7.
  • The Windows server is powered off once the VCSA is brought online, this means any other components, VMware or third party, need to be migrated off the Windows server in advance or they will no longer work (don’t forget to move and update any scripts that may live on the Windows server).
  • If you are using Update Manager the VCSA now includes an embedded Update Manager instance.
  • You must check compatibility of any third party products and plugins that might be used for backups, anti-virus, monitoring, etc. as these may need upgrading for vSphere 6.7 compatibility.
  • To check version compatibility with other VMware products see the Product Interoperability Matrix.
  • The points above are especially important since at the time of writing vSphere 6.7 is new enough that other VMware and third party products may not have released compatible versions. Verify before installing vSphere 6.7 and review the Release Notes and Important information before upgrading to vSphere 6.7 KB.

Hardware Considerations

  • The VCSA with embedded PSC requires the following hardware resources (disk can be thin provisioned)
    • Tiny (up to 10 hosts, 100 VMs) – 2 CPUs, 10 GB RAM.
    • Small (up to 100 hosts, 1000 VMs) – 4 CPUs, 16 GB RAM.
    • Medium (up to 400 hosts, 4000 VMs) – 8 CPUs, 24 GB RAM.
    • Large (up to 1000 hosts, 10,000 VMs) – 16 CPUs, 32 GB RAM.
    • X-Large (up to 2000 hosts, 35,000 VMs) – 24 CPUs, 48 GB RAM – new to v6.5.
  • Storage requirements for the smallest environments start at 250 GB and increase depending on your specific database requirements. See the Storage Requirements document for further details.
  • Where the PSC is deployed as a separate appliance this requires 2 CPUs, 4 GB RAM, 60 GB disk.
  • Environments with ESXi host(s) with more than 512 LUNs and 2048 paths should be sized large or x-large.
  • To help with selecting the appropriate storage size for the appliance calculate the size of your existing VCS database here.

Architectural Considerations

  • The migration tool supports different deployment topologies but can not, make changes to the topology and SSO domain configuration.
  • For more information on the deployment topologies available with vCenter 6.x see vCenter Server and Platform Services Controller Deployment Types.
  • A series of videos covering vCenter Server and Platform Services Architecture can be found here. If you require further assistance with vCenter planning see also the vSphere Topology and Upgrade Planning Tool here,
  • Most deployments will include the vCenter Server and PSC in one appliance, following the embedded deployment model, which I will use in this guide.
  • Consider if the default self-signed certificates are sufficient or if you want to replace with custom CA or VMware CA signed certs, see Installing vCenter Internal CA signed SSL Certificates for more information.

embedded

Other Considerations

  • Ensure you have a good backup of the vCenter Server and the database.
  • Variables such as FQDN resolution, database permissions and access to the licensing portal should all be in place since we are upgrading an existing vCenter solution.
  • All vSphere components should be configured to use an NTP server. The installation can fail or the vCenter Server Appliance vpxd service may not be able to start if the clocks are unsynchronized.
  • The ESXi host on which you deploy the VCSA should not be in lockdown or maintenance mode.
  • You will need the SSO administrator login details and if the Windows VCS service runs as a service account then the account must have replace a process level token permission.
  • Local Windows users that have vSphere permissions are not migrated since they are specific to the Windows server, all SSO users and permissions are migrated.
  • The upgrade can be easily rolled back by following this KB.
  • Migration of vCenter using DHCP, or services with custom ports, is not supported. The settings of only one physical network adapter are migrated.
  • Downtime varies depending on the amount of data you are migrating and is calculated when running the migration wizard.
  • A list of Required Ports for vCenter Server and PSC can be found here.
  • The configuration maximums for vSphere 6.7 can be found here.
  • In vSphere 6.7 TLS 1.2 is enabled by default. TLS 1.0 and TLS 1.1 are disabled by default, review the Release Notes for more information.
  • There are a number of Intel and AMD CPUs no longer supported with vSphere 6.7, review the Release Notes for a full list of unsupported processors.

Process

Before we begin if your existing Windows vCenter is virtual it may be beneficial to rename the vCenter virtual machine name in the vSphere inventory to include -old or equivalent. While the hostname and IP are migrated the vSphere inventory name of the VM cannot be a duplicate. The old server is powered down but not deleted so that we have a back out.

Download the VMware vCenter Server Appliance 6.7 ISO from VMware downloads: v6.7.0. Mount the ISO on your computer. The VCSA 6.5 installer is compatible with Mac, Linux, and Windows. Copy the migration-assistant folder to the Windows vCenter Server (and PSC server if external). If the PSC is running on a different Windows server then you must run the Migration Assistant on the PSC server first and migrate following the instructions below, then complete the same process on the Windows vCenter Server.

Start the VMware-Migration-Assistant and enter the SSO Administrator credentials to start running pre-checks.

VCSA_Migration_1

If all checks complete successfully the Migration Assistant will finish at ‘waiting for migration to start’.

On a different machine from your Windows vCenter and PSC server(s) open the vcsa-ui-installer folder file located on the root of the ISO. Browse to the corresponding directory for your operating system, e.g. \vcsa-ui-installer\win32. Right click Installer and select Run as administrator. The vCenter Server Appliance Installer will open, click Migrate.

VCSA_Migration_2

The migration is split into 2 stages; stage 1 deploys the new appliance with temporary network settings, there is no outage to the Windows vCenter at this stage. Stage 2 migrates data and network settings over to the new appliance and shuts down the Windows server. We begin with deploying the appliance. Click Next.

VCSA_Migration_3

Accept the license terms and click Next.

VCSA_Migration_4

Enter the details of the vCenter Server to migrate, then click Next.

VCSA_Migration_5

Enter the FQDN or IP address of the host, or vCenter upon which you wish to deploy the new VCSA. Enter the credentials of an administrative or root user and click Next. The installer will validate access, if prompted with an untrusted SSL certificate message click Yes to continue. Tip – connect to the vCenter for visibility of any networks using a distributed switch, connecting to the host direct will only pull back networks using a standard switch.

VCSA_Migration_6

Enter the virtual appliance VM name, this is the name that appears in the vSphere inventory as mentioned earlier. The host name of the vCenter Server will automatically be migrated. Click Next.

VCSA_Migration_7

Select the appropriate deployment size for your environment and click Next.

VCSA_Migration_8

Select the datastore to locate the virtual appliance and click Next. Configure the temporary network settings for the appliance. These will only be used during migration of the data, once complete the temporary settings are discarded and the VCSA assumes the identity, including IP settings, of the Windows vCenter Server. Click Next.

VCSA_Migration_9

Review the settings on the summary page and click Finish. The VCSA will now be deployed. Once complete click Continue to being the second stage of the migration.

VCSA_Migration_10

Click Next to begin the migration wizard.

VCSA_Migration_11

The source vCenter details are imported from stage 1.

VCSA_Migration_12

As my source Windows vCenter was joined to a domain I am prompted for credentials to join the VCSA to the domain.

VCSA_Migration_13

Select the data to migrate and click Next.

VCSA_Migration_14

Select whether or not to join the VMware Customer Experience Improvement Program and click Next.

VCSA_Migration_15

Review the summary page and click Finish. Data will now be migrated to the VCSA, once complete the Windows vCenter Server will be powered off and the network settings transferred to the VCSA. If you urgently need to power back on the Windows server to retrieve files or such like, then do so with the vNICs disconnected, otherwise you will cause an IP/host name conflict on the network.

VCSA_Migration_16

Post-Installation

Connect to the vCenter post install using the IP or FQDN of the vCenter. Access vSphere by clicking either Launch vSphere Client (HTML5) or Launch vSphere Web Client (FLEX). As the web client will be depreciated in future versions, and the HTML5 client is now nearly at full feature parity, we will use the HTML5 vSphere client.

Windows_vCenter67_14

Management features of the VCSA can be accessed by browsing to the IP or FQDN of the vCenter on port 5480. The login is the root account we configured a password for during the migration wizard.

VCSA_Management

vCenter Server Appliance 6.7 Install Guide

VMware vCenter Server pools ESXi host resources to provide a rich feature set delivering high availability and fault tolerance to virtual machines. The vCenter Server is a centralised management application and can be deployed as a virtual appliance or Windows machine. It should be noted that vCenter 6.7 is the final release where Windows modules will be available, see here for more information. All future releases will only be available as vCenter Server Appliance (VCSA) which is the preferred deployment method of vCenter Server. An existing Windows vCenter can be migrated to VCSA by following the steps in Migrating Windows vCenter Server to VCSA 6.7 This post gives a walk through on a clean installation of VCSA 6.7.

vCenter 6.7: Download | Release Notes | What’s New | VMware DocsvSphere Central

Altaro-Free-VMware-ebook-Mastering-vSphere-468x60

About VCSA

migrate2vcsaThe VCSA is a pre-configured virtual appliance built on Project Photon OS. Since the OS has been developed by VMware it benefits from enhanced performance and boot times over the previous Linux based appliance. Furthermore the embedded vPostgres database means VMware have full control of the software stack, resulting in significant optimisation for vSphere environments and quicker release of security patches and bug fixes. The VCSA scales up to 2000 hosts and 35,000 virtual machines. A couple of releases ago the VCSA reached feature parity with its Windows counterpart, and is now the preferred deployment method for vCenter Server. Features such as Update Manager are bundled into the VCSA, as well as file based backup and restore, and vCenter High Availability. The appliance also saves operating system license costs and is quicker and easier to deploy and patch.

Software Considerations

  • VCSA 6.7 must be deployed to an ESXi host or vCenter running v5.5 or above. However, all hosts you intend to connect to vCenter Server 6.7 should be running ESXi 6.0 or above, hosts running 5.5 and earlier cannot be managed by vCenter 6.7 and do not have a direct upgrade path to 6.7.
  • You must check compatibility of any third party products and plugins that might be used for backups, anti-virus, monitoring, etc. as these may need upgrading for vSphere 6.7 compatibility.
  • To check version compatibility with other VMware products see the Product Interoperability Matrix.
  • The points above are especially important since at the time of writing vSphere 6.7 is new enough that other VMware and third party products may not have released compatible versions. Verify before installing vSphere 6.7 and review the Release Notes and Important information before upgrading to vSphere 6.7 KB.

Architectural Considerations

  • When implementing a new vSphere 6.7 environment you should plan your topology in accordance with the VMware vCenter Server and Platform Services Controller Deployment Types.
  • A series of videos covering vCenter Server and Platform Services Architecture can be found here. If you require further assistance with vCenter planning see also the vSphere Topology and Upgrade Planning Tool here,
  • Most deployments will include the vCenter Server and PSC in one appliance, following the embedded deployment model, which I will use in this guide.
  • Greenfield deployments of vSphere 6.7 can take advantage of Embedded PSC with Enhanced Linked Mode, providing native vCenter Server HA support, and removal of SSO site boundaries.
  • Consider if the default self-signed certificates are sufficient or if you want to replace with custom CA or VMware CA signed certs, see Installing vCenter Internal CA signed SSL Certificates for more information.

embedded

Other Considerations

  • The VCSA with embedded PSC requires the following hardware resources (disk can be thin provisioned)
    • Tiny (up to 10 hosts, 100 VMs) – 2 CPUs, 10 GB RAM.
    • Small (up to 100 hosts, 1000 VMs) – 4 CPUs, 16 GB RAM.
    • Medium (up to 400 hosts, 4000 VMs) – 8 CPUs, 24 GB RAM.
    • Large (up to 1000 hosts, 10,000 VMs) – 16 CPUs, 32 GB RAM.
    • X-Large (up to 2000 hosts, 35,000 VMs) – 24 CPUs, 48 GB RAM – new to v6.5.
  • Storage requirements for the smallest environments start at 250 GB and increase depending on your specific database requirements. See the Storage Requirements document for further details.
  • Where the PSC is deployed as a separate appliance this requires 2 CPUs, 4 GB RAM, 60 GB disk.
  • Environments with ESXi host(s) with more than 512 LUNs and 2048 paths should be sized large or x-large.
  • The ESXi host on which you deploy the VCSA should not be in lockdown or maintenance mode.
  • All vSphere components should be configured to use an NTP server. The installation can fail or the vCenter Server Appliance vpxd service may not be able to start if the clocks are unsynchronized.
  • FQDN resolution should be in place when deploying vCenter Server.
  • A list of Required Ports for vCenter Server and PSC can be found here.
  • The configuration maximums for vSphere 6.7 can be found here.
  • In vSphere 6.7 TLS 1.2 is enabled by default. TLS 1.0 and TLS 1.1 are disabled by default, review the Release Notes for more information.
  • There are a number of Intel and AMD CPUs no longer supported with vSphere 6.7, review the Release Notes for a full list of unsupported processors.

Installation

Download the VMware vCenter Server Appliance 6.7 ISO from VMware downloads: v6.7.0.

Mount the ISO on your computer. The VCSA 6.7 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.

VCSA_1

The installation is split into 2 stages, we begin with deploying the appliance. Click Next.

VCSA_2

Accept the license agreement and click Next.

VCSA_3

Select the deployment model, in this example we will be using an embedded deployment combining the vCenter Server and Platform Services Controller in one appliance, click Next.

VCSA_4

Enter the FQDN or IP address of the host, or vCenter upon which you wish to deploy the new VCSA. Enter the credentials of an administrative or root user and click Next. The installer will validate access, if prompted with an untrusted SSL certificate message click Yes to continue. Tip – connect to the vCenter for visibility of any networks using a distributed switch, connecting to the host direct will only pull back networks using a standard switch.

VCSA_5

Enter the VM name for the VCSA and a root password, click Next.

VCSA_6

Select the deployment size in line with the number of hosts and virtual machines that will be managed, click Next.

VCSA_7

Select the datastore where the VCSA will be deployed, select thin provisioning if required, and click Next. Configure the network settings for the appliance and click Next.

VCSA_8

On the summary page click Finish. The appliance will now be deployed.

VCSA_9

With the VCSA now deployed we can move on to stage 2, click Continue.

VCSA_10

Click Next to being the VCSA setup.

VCSA_11

Configure the NTP servers, enable SSH access if required, and click Next.

VCSA_12

Enter a unique SSO domain name, the default is vsphere.local. The SSO domain name should not be the same as your Active Directory Domain. Configure a password for the SSO administrator, click Next.

VCSA_13

Select or deselect the customer experience improvement program box and click Next.

VCSA_14

Review the details on the summary page and click Finish. Click Ok to acknowledge that the VCSA setup cannot be paused or stopped once started. When the installer is complete click Close to close the wizard.

Post-Installation

Connect to the vCenter post install using the IP or FQDN of the vCenter. Access vSphere by clicking either Launch vSphere Client (HTML5) or Launch vSphere Web Client (FLEX). As the web client will be depreciated in future versions, and the HTML5 client is now nearly at full feature parity, we will use the HTML5 vSphere client.

Windows_vCenter67_14

You must apply a new vCenter license key within 60 days. If you have purchased vCenter Server then log into your licensing portal here. If the license key does not appear then check with your VMware account manager. Log in to the vSphere Web Client using the SSO administrator login.  From the Menu drop-down click Administration,

Windows_vCenter67_16

Under Licensing select Licenses. First we need to add a new license key, click Add New Licenses. Enter the new license key for vCenter Server, click Next. If applicable assign a name to the licence, click Next. Click Finish to add the license key.

Windows_vCenter67_15

Switch to Assets, the vCenter Server is listed in evaluation mode. Highlight the vCenter and click Assign License. Select the license key and click Ok.

Windows_vCenter67_17

If you have an Active Directory domain then vCenter can use this as an identity source. First ensure the vCenter is joined to the domain; from the Menu drop-down click Administration. Under Single Sign On click Configuration. Select the Active Directory Domain tab and verify the vCenter is domain joined. Change to the Identity Sources tab and click Add Identity Source. Fill in the Active Directory details for your domain and click Ok.

Windows_vCenter67_18

You can now add permissions to vCenter objects such as datacenters, clusters, folders, individual virtual machines, etc. for Active Directory users and groups. To learn more about vSphere permissions click here.

To start adding ESXi hosts to vCenter click the Menu drop-down and select Hosts and Clusters. Right click the vCenter and select New Datacenter, give the datacenter a name and click Ok. Right click the datacenter and select Add Host. Follow the onscreen wizard to add a host. Creating clusters and configuring vCenter is beyond the scope of this post, for assistance follow the documentation links at the top of the page.

Windows_vCenter67_19

Windows vCenter Server 6.7 Install Guide

VMware vCenter Server pools ESXi host resources to provide a rich feature set delivering high availability and fault tolerance to virtual machines. The vCenter Server is a centralised management application and can be deployed as a virtual appliance or Windows machine. It should be noted that vCenter 6.7 is the final release where Windows modules will be available, see here for more information. All future releases will only be available in VCSA form, if you have not already started planning migration to VCSA see vCenter Server Appliance 6.7 Install Guide and Migrating Windows vCenter Server to VCSA 6.7. This post gives a walk through on a clean installation of vCenter Server 6.7 on Windows Server 2016.

vCenter 6.7: Download | Release Notes | What’s New | VMware DocsvSphere Central

Software Considerations

  • The operating system should be 64 bit and Windows Server 2008 SP2 or above.
  • For environments with up to 20 hosts and 200 VMs the bundled internal PostgreSQL database can be used.
  • If an external database is used it should be Microsoft SQL Server 2008 R2 SP2 or above, or Oracle 11g or 12c. You can review a full list of compatible versions at the Database Interoperability Matrix.
  • The account used for external database authentication requires Oracle DBA role, or SQL sysadmin server role, or db_owner fixed database role. For a full list of explicit permissions review the Database Permission Requirements.
  • You must check compatibility of any third party products and plugins that might be used for backups, anti-virus, monitoring, etc. as these may need upgrading for vSphere 6.7 compatibility.
  • Any hosts you want to add to vCenter 6.7 should be running version 6.0 or above, 5.5 and earlier will not work and do not have a direct upgrade path to 6.7.
  • To check version compatibility with other VMware products see the Product Interoperability Matrix.
  • The points above are especially important since at the time of writing vSphere 6.7 is new enough that other VMware and third party products may not have released compatible versions. Verify before installing vSphere 6.7 and review the Release Notes and Important information before upgrading to vSphere 6.7 KB.

Architectural Considerations

  • As noted above the Windows modules will not be included for future versions, therefore the recommended installation method for vCenter 6.7 is the vCenter Server Appliance (VCSA).
  • When implementing a new vSphere 6.7 environment you should plan your topology in accordance with the VMware vCenter Server and Platform Services Controller Deployment Types.
  • A series of videos covering vCenter Server and Platform Services Architecture can be found here. If you require further assistance with vCenter planning see also the vSphere Topology and Upgrade Planning Tool here,
  • Most deployments will include the vCenter Server and PSC on one server, following the embedded deployment model, which I will use in this guide.
  • Greenfield deployments of vSphere 6.7 can take advantage of Embedded PSC with Enhanced Linked Mode, providing native vCenter Server HA support, and removal of SSO site boundaries.

embedded

Hardware Considerations

  • A Windows based vCenter Server can be installed on either a physical or virtual machine. Windows vCenter Server with embedded PSC requires the following hardware resources:
    • Tiny (up to 10 hosts, 100 VMs) – 2 CPUs, 10 GB RAM.
    • Small (up to 100 hosts, 1000 VMs) – 4 CPUs, 16 GB RAM.
    • Medium (up to 400 hosts, 4000 VMs) – 8 CPUs, 24 GB RAM.
    • Large (up to 1000 hosts, 10,000 VMs) – 16 CPUs, 32 GB RAM.
    • X-Large (up to 2000 hosts, 35,000 VMs) – 24 CPUs, 48 GB RAM – new to v6.5.
  • Where the PSC is deployed on a separate machine this requires 2 CPUs, 4 GB RAM.
  • Environments with ESXi host(s) with more than 512 LUNs and 2048 paths should be sized large or x-large.
  • The Windows vCenter Server requires the following free disk space for installation: (the first 2 may not necessarily be the system drive depending on installation location) Program Files 6 GB, Program Data 8 GB, System folder 3 GB. The PSC machine requires; Program Files 1 GB, Program Data 2 GB, System folder 1 GB.
  • There are a number of Intel and AMD CPUs no longer supported with vSphere 6.7, review the Release Notes for a full list of unsupported processors.

Other Considerations

  • It may be necessary to temporarily stop any third party software which could interfere with the installer, such as anti-virus scanner.
  • If the vCenter Server services are running as a user other than the Local System account then the user must be a member of the administrators group and have the following permissions; log on as a service, act as part of the operating system.
  • Verify that the local machine policy allows assigning Log on as a batch job rights to new local users.
  • All vSphere components should be configured to use the same NTP server.
  • FQDN resolution should be in place when deploying vCenter Server.
  • A list of Required Ports for vCenter Server and PSC can be found here.
  • The configuration maximums for vSphere 6.7 can be found here.
  • In vSphere 6.7 TLS 1.2 is enabled by default. TLS 1.0 and TLS 1.1 are disabled by default, review the Release Notes for more information.

Create Data Source

Before beginning if you intend to use vCenter Server with an external SQL database you must configure a 64-bit ODBC data source for external databases. You may also need to install the Microsoft ODBC Driver for SQL Server. ODBC Data Source Administrator can be accessed via Control Panel > Administrative Tools. Click System DNS, Add and input the details for the external database, test the data source before continuing. If you are using the internal Postgres database then the System DSN is added automatically during installation.

odbc

Installation

Download the VMware vCenter Server and Modules for Windows ISO from VMware downloads: v6.7.0.

Mount the ISO and right click autorun.exe, select Run as administrator. The VMware vCenter Installer will open. Ensure vCenter Server for Windows is selected and click Install.

Windows_vCenter67_1

The vCenter Server 6.7 Installer will open in a separate window, click Next.

Windows_vCenter67_2

Accept the end user license agreement and click Next.

Windows_vCenter67_3

In this guide we will be using an embedded deployment model. If you are using an external deployment model the PSC component must be installed first before the vCenter. Select the deployment type and click Next. If the Windows server does not have sufficient resources allocated the installer will error at this stage.

Windows_vCenter67_4

Enter the FQDN in the System Name field and click Next.

Windows_vCenter67_5

Create a new Single Sign-On domain, or join the vCenter to an existing SSO domain. If you are creating a new SSO domain either leaves as the default vsphere.local or create a new SSO domain name, (not the same as your Active Directory name). Configure a password for the SSO administrator account and a vCenter specific site name, click Next. Note: vCenter 6.7 is the last release where a SSO site name will need to be provided.

Windows_vCenter67_6

Select whether to run vCenter services as the local system account or enter details of a service account and click Next. Ensure the account running vCenter services has been granted permissions as per the other considerations section of this guide.

Windows_vCenter67_7

Select an embedded Postgre database or point the installer to the DSN for an external database, click Next.

Windows_vCenter67_8

Accept the default port configuration and click Next.

Windows_vCenter67_9

Select the directory to install vCenter services and click Next.

Windows_vCenter67_10

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

Windows_vCenter67_11

Check the configuration on the review page and click Install to begin the installation process.

Windows_vCenter67_12

Once the installation has completed click Finish.

Windows_vCenter67_13

Post-Installation

Connect to the vCenter post install using the IP or FQDN of the vCenter. Access vSphere by clicking either Launch vSphere Client (HTML5) or Launch vSphere Web Client (FLEX). As the web client will be depreciated in future versions, and the HTML5 client is now nearly at full feature parity, we will use the HTML5 vSphere client.

Windows_vCenter67_14

You must apply a new vCenter license key within 60 days. If you have purchased vCenter Server then log into your licensing portal here. If the license key does not appear then check with your VMware account manager. Log in to the vSphere Web Client using the SSO administrator login.  From the Menu drop-down click Administration,

Windows_vCenter67_16

Under Licensing select Licenses. First we need to add a new license key, click Add New Licenses. Enter the new license key for vCenter Server, click Next. If applicable assign a name to the licence, click Next. Click Finish to add the license key.

Windows_vCenter67_15

Switch to Assets, the vCenter Server is listed in evaluation mode. Highlight the vCenter and click Assign License. Select the license key and click Ok.

Windows_vCenter67_17

If you have an Active Directory domain then vCenter can use this as an identity source. First ensure the vCenter is joined to the domain; from the Menu drop-down click Administration. Under Single Sign On click Configuration. Select the Active Directory Domain tab and verify the vCenter is domain joined. Change to the Identity Sources tab and click Add Identity Source. Fill in the Active Directory details for your domain and click Ok.

Windows_vCenter67_18

You can now add permissions to vCenter objects such as datacenters, clusters, folders, individual virtual machines, etc. for Active Directory users and groups. To learn more about vSphere permissions click here.

To start adding ESXi hosts to vCenter click the Menu drop-down and select Hosts and Clusters. Right click the vCenter and select New Datacenter, give the datacenter a name and click Ok. Right click the datacenter and select Add Host. Follow the onscreen wizard to add a host. Creating clusters and configuring vCenter is beyond the scope of this post, for assistance follow the documentation links at the top of the page.

Windows_vCenter67_19

Provisioning Virtual Machines with PowervRA

This post will walk through using PowervRA to provision virtual machines from vRA catalog items. PowervRA is a powerful tool allowing us to automate and customise vRA configuration and deployments by leveraging the RESTFUL API. We’ll cover requesting catalog items using both the default settings and with additional values or customisation using a JSON file. For more information review the PowervRA documentation here, the full syntax for Request-vRACatalogItem can be found here.

PowervRA can be installed direct from the PowerShell gallery.

Install-Module -Name PowervRA

Alternatively you can download from GitHub here, drop the PowervRA folder into C:\Program Files\WindowsPowerShell\Modules, and then import.

Import-Module PowervRA

Use Connect-vRAServer to establish a connection to the vRA appliance. This will prompt for a username and password.

Connect-vRAServer -Server <vRA Server> -Tenant <Tenant Name>
Connect-vRAServer -Server vralab01.corp.local -Tenant esxsi -IgnoreCertRequirements

You can also add the -Username switch and -Password switch, or -Credential to add a Powershell credential file. If you are using self signed certs add -IgnoreCertRequirements.

Use Get-vRACatalogItems to list all catalog items the user has access to. Add the -Name switch to list details for a specific catalog item. Make a note of the Id, this is required to request the catalog item.

Get-vRACatalogItem
Get-vRACatalogItem -Name <Catalog Item Name>
Get-vRACatalogItem -Name PSTestBlueprint

Use Request-vRACatalogItem to make the request, you can also add -Wait to wait for the request to complete, and -Verbose to show the event log.

Request-vRACatalogItem -Id <Catalog Item Id>
Request-vRACatalogItem -Id 78eddfcc-c9dd-4104-abd6-218b6ff1e9fa -Wait -Verbose 

We can even do something like:

$CatalogItemId = (Get-vRACatalogItem -Name PSTestBlueprint).Id
Request-vRACatalogItem -Id $CatalogItemId

powervra

In this scenario we want to go further and add values for some custom properties to the request. The request can be customised using a JSON file.

Output the catalog item properties to a JSON file for customisation.

Get-vRACatalogItemRequestTemplate -Name <Catalog Item Name> | Out-File path\file.json
Get-vRACatalogItemRequestTemplate -Name PSBlueprintTest | Out-File C:\requestTemplate.json

Set $json as the updated JSON file. You can verify this has worked and the contents of the JSON file using Write-Output.

$json = Get-Content path\file.json -Raw
$json = Get-Content C:\requestTemplate.json -Raw
Write-Output $json

powervra_1

Update and save the JSON file as required, for example adding the value for a custom property, or amending the CPU / memory allocation.

vra_json

We can now request the catalog item using the JSON file.

Request-vRACatalogItem -JSON $json

powervra_2

When the request is submitted either monitor through Powershell, if you used the verbose switch, or follow the status in the vRA portal as normal under the requests tab.

Setting Manual DFW Override for NSX Restore

The recommended restore process for NSX Manager is to deploy a new OVA of the same version, and restore the configuration. After a recent failed upgrade we needed to restore NSX Manager, so deployed a new OVA with the same network settings. After the new NSX Manager was powered on we were unable to ping the IP address, this was because there were no default rules allowing access to the VM, and since the existing NSX Manager was down we were unable to connect to the UI or API to add the required firewall rules. NSX Manager is normally excluded from Distributed Firewall (DFW) by default, however at this point the hosts saw it as any other VM, since we had not yet restored the configuration. Therefore we needed to add a manual override to clear the filters applied to the new NSX Manager, allowing us to connect and restore the configuration. The following commands were run on the host where the new NSX Manager OVA was deployed, using SSH. For further guidance on the backup and restore process of NSX see the NSX Backup and Restore post.

Disclaimer: the steps below are advanced commands using vsipfwcli which is an extremely powerful tool. You should engage VMware GSS if doing this on anything other than a lab environment, you should also understand the impact of stopping the vsfwd service on the host and the impact this may have on any other VMs with a DFW policy of fail closed.

net-stats -l lists the NIC details of the VMs running on the host, verify the new NSX Manager is present.

/etc/init.d/vShield-Stateful-Firewall stop stops the vsfwd user world agent, you can also use status to display the status.

vsfwd

summarize-dvfilter lists port and filter details, we need the port name for the VM, e.g. nic-38549-eth0-vmware-sfw.2.

DFW_1

vsipioctl getrules -f nic-38549-eth0-vmware-sfw.2 lists the existing filters applied to the port, replace the port name with your own, from the output check to confirm the ruleset name, e.g. ruleset domain-c17.

DFW_2

vsipioctl vsipfwcli -f nic-38549-eth0-vmware-sfw.2 -c "create ruleset domain-c17;" creates a new empty ruleset with the same name, overriding the previous ruleset applied to the port. Replace the port name with your own and the ruleset name if it is different.

vsipioctl getrules -f nic-38549-eth0-vmware-sfw.2 again lists the existing filters applied to the port, the ruleset should now be empty as no filters are applied.

DFW_3

The NSX Manager is now pinging and the normal restore process can resume; connect to the web interface by browsing to the IP address or FQDN of the NSX Manager.

Restore_NSX_1

Select Backup & Restore.

Restore_NSX_2

Select the appropriate restore point and click Restore. Click Yes to confirm.

Restore_NSX_3

The restore generally takes 5-10 minutes, once complete you will see a restore completed successfully message in a blue banner on the Summary page. You may need to log out and log back in after the config is restored.

Restore_NSX_4

Once the NSX Manager services have started you can manage the DFW from the vSphere web client as normal. Remember to start the vsfwd service again on the host, after the vsfwd service is started the empty ruleset we created earlier is replaced with the original ruleset when the host syncs with NSX Manager.

/etc/init.d/vShield-Stateful-Firewall start starts the vsfwd user world agent, you can also use status to display the status.