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

Altaro Continuous Data Protection

Altaro v7.6 introduces a Continuous Data Protection (CDP) feature which reduces data loss by providing Recovery Point Objectives (RPO) of up to 5 minutes. Altaro CDP works by saving a point in time copy of the virtual machine based on snapshots at set intervals, configurable per host or per virtual machine. The frequency options available are every 5 minutes, 15 minutes, 30 minutes, every hour, 4 hours, 8 hours, or 12 hours. Each version of a CDP backup is retained for 4 hours since the last successful backup, after this CDP backups are merged into a single recovery point and kept in accordance with your own configured retention policy.

Altaro v7.6 is available now, you can read about what is new in v7.6 here. CDP is initially available for Hyper-V, with VMware expected mid Q2 this year. This post will be updated when VMware CDP compatiblity is added.

Altaro_CDP_1

Configuring CDP

  • If you do not already have Altaro VM Backup installed see the Altaro VM Backup Install and Overview post. You can download a copy of Altaro here.
  • The CDP Settings option can be accessed from the navigation pane of the Altaro VM Backup management console, under Setup. Hosts that have been added to Altaro are listed, along with any discovered VMs.
  • Use the Enable CDP check box and Maximum Frequency drop down to configure CDP with the desired settings.

Altaro_CDP_2

  • When configuring CDP there should already be a backup schedule and backup location in place for the virtual machines. If you have not yet configured this part then see the install and overview post referenced above.
  • Click Save Changes to commit the CDP configuration.

Altaro_CDP_4

  • The first time you configure CDP backups the VM Backup management console will display a warning about the Backup Health Monitor. The Backup Health Monitor verifies the state of backup data, during which time backups cannot run.
  • Depending on your environment and desired configuration you can change the schedule of the Backup Health Monitor to not conflict with CDP backups.
  • Once CDP backups are in use they become available restore points for restoring virtual machines.

Altaro_CDP_3

  • The Backup Health Monitor can also be configured from the navigation pane under Sandbox & Configuration.

Altaro_CDP_5

In summary, Altaro CDP boosts business continuity by allowing administrators to recover to a more granular point in time; thereby reducing data loss from virtual machine restores. The feature is easy to configure and the frequency options provide near continuous data protection with the maximum data loss being up to 5 minutes, this along with application consistent backups should be sufficient protection for most business critcal applications. When planning implementation of a CDP model you should consider other factors such as network bandwidth, and hypervisor performance, for example having a high number of machines taking snapshots every 5 minutes on the same host may add a CPU/memory overhead.

Altaro v7.6 is available now, you can download here.

Altaro VM Backup 7.5 Install and Overview

In this post we will install and configure Altaro VM Backup 7.5 whilst taking a look at the some of the key features. Version 7.5 introduces cloud backup to Azure and restore from Azure to Altaro instances in different locations. The Cloud Management Console (CMC) allows for users to monitor and manage all installations of Altaro through an intuitive and easy to use web client accessible anywhere. Support for vSphere 6.5 is also now included, for a full list of the new functionality see this post.

Overview

Altaro allows users to backup VMware and Hyper-V environments; taking application and file consistent backups of Windows, Linux, and applications compatible with the Microsoft VSS writer including Exchange and SQL. Backups benefit from compression, inline deduplication, and military grade encryption configurable right down to individual VM level. Granular restores also allow for individual file or email restores, as well as sandbox restores. Furthermore Altaro’s unique Backup Health Monitor proactively monitors backups and automatically repairs or replaces any corruption as part of the next backup job. Advanced automation and reporting can be configured using Altaro’s built in REST API. Altaro has easily accessible pricing and licensing information, and multiple channels to engage technical support including live chat from within the management console itself.

  • See the graphic below for a summary of Altaro features for each licensing option. For full product, version, and pricing information click here.
  • The Altaro VM Backup Quick Start Guide can be reviewed here, and full product user guides here. Altaro Support and FAQ can be accessed here.

Versions

Install

The installation of the main backup console is simple and quick. Download the installer to a Windows machine and run as administrator. Accept the license agreement, set the destination, and hit Install. Altaro VM Backup can run on 64 bit versions of Windows 7, 8, or 10, and Windows Server 2008 R2 through to Windows 2016 (including Hyper-V and Core versions).

Once the install has completed open the management console. The VM Backup management console offers an intuitive user interface, allowing for local or remote management of multiple Altaro instances. In this example we’ll connect to the instance running on the local machine.

Altaro_Console_1

After connecting to the new instance the dashboard will load with a handy quick setup workflow.

Altaro_Console_2

Step 1 is to add the hosts to backup. In this example we’re using VMware so after clicking Add Hyper V / VMware Host select VMware vCenter Server and Next.

Altaro_Console_3

Enter and validate the vCenter Server information using Test Connection, click Next.

Altaro_Console_5

Review the hosts detected and click Finish. The hosts and inventory information from the specified vCenter Server are now added to the management console. We can see the host status and number of VMs for each host that has been added.

Altaro_Console_6

The product comes with a 30 day fully functioning trial. At any time you can install a license key by clicking Manage License under Setup and Hosts.

Step 2 is to configure a backup location, this can be a physical drive or network path. From the dashboard workflow click Choose Where to Store Backups.

Altaro_Console_7

For the purposes of this lab installation we will use the data drive of the Windows server.

Altaro_Console_8

Multiple backup locations can be added. Once a backup location is configured you can drag and drop VMs, clusters, datacenters, or vCenters into the appropriate area. After adding a local or LAN based backup location you can also add an offsite location, such as a WAN or Azure target. When the objects you require backing up are all assigned a backup location click Save Changes.

Altaro_Console_9

The final step in the workflow is to take our first backup, to take an on demand backup straight away click Take First Backup. Backup schedules and retention policies can be configured from the navigation menu on the left hand side. You’ll also notice Notifications and Advanced Settings where deduplication, encryption, and CBT can be configured on a per object basis, as well as providing the ability to exclude certain drives. Application consistent backups and truncating logs can be enabled under VSS Settings.

Cloud Management Console

The Cloud Management Console (CMC) can be accessed here. When you first login the getting started dashboard will be displayed, use the workflow to link an Altaro VM Backup installation.

Altaro_CMC_1

A one time access key is generated to link the Cloud Management Console with the Altaro VM Backup installation. From the management console click the CMC button and enter this code to pair the installation with the CMC.

Altaro_CMC_3

Once CMC is paired with your Altaro VM Backup instance you can monitor and manage the backup environment using the web client. Multiple installations can be added to CMC.

Altaro_CMC_2