Migrate VM from Hyper-V to vSphere with Pre-Installed VMware Tools

Note: This post is written specifically for VMware Tools 10. If you’re looking for a procedure that works with VMware Tools 11 or VMware Tools 12, you can see my latest blog post here.

One of things I rarely get to do is work with Hyper-V, however, I’m starting to get more exposure to it as I encounter more organizations that are either running all Hyper-V or are doing some type of migration between Hyper-V and vSphere.

One of the biggest challenges that I’ve both heard and encountered in my own testing is really around drivers. If you’re making the move from Hyper-V to vSphere, you’re going to have to figure out how to get your network settings migrated along with the virtual machines, whether manually or in a more automated way.

And yes! You can definitely use Zerto as the migration vehicle and take advantage of benefits like:

  • Non-disruptive replication
  • Automatic conversion of .vhdx to .vmdk (and vice versa)
  • Non-disruptive testing before migrating
  • Boot Order
  • Re-IP

For re-IP operations , Zerto requires that VMware Tools is installed running on the VMs you want to protect.

Zerto Administration Guide for vSphere

There are two ways to accomplish a cross-hypervisor migration or failover with Zerto.

Installing the VMware Tools is going to be required either way. If you choose to install the VMware Tools before migrating or protecting, you are going to get much better results.

Post-installation of the VMware Tools will prevent the capability to automatically re-IP or even keep the existing network settings, therefore, you will end up having to hand-IP every VM you migrate/failover, which seriously cuts into any established recovery time objective (RTO) and leaves more room for human error.

Overview

We will walk through what you need to do in order to get VMware Tools prepared for installation on a Hyper-V virtual machine. After that, there is a video at the end of this post that will pick demonstrate successful pre-installation of VMware Tools, replication, and migration of a VM from Hyper-V.

At the time of this writing, the versions of Zerto, Hyper-V, and vSphere that I have performed the steps that follow are:

  • Zerto 8.0
  • Hyper-V 2016
  • vSphere 6.7 (VMware Tools from 6.7 as well)

I also wanted to give a shout out to Justin Paul, who had written a similar blog post about this same subject back in 2018. You can find his original post here: https://bit.ly/3dfWKdm

Pre-Requisites

Like a recipe, you’re going to need a few things:

VMware Tools

You will need to obtain a copy of the VMware Tools, and it must be a version supported by your version of vSphere. You can use this handy >>VMware version mapping file<< to see what version of the tools you’d need.

You can get the tools package by mounting the VMware Tools ISO to any virtual machine in your vSphere environment, browsing the virtual CD-ROM, and copying all the files to your desktop. If you don’t have an environment available, you can also >>download the installer<< straight from VMware (requires a My VMware account).

Since you only need a few files from the installer package, start the installer on your desktop and wait for the welcome screen to load. Once that screen loads, if you’re on a physical machine (laptop, PC, etc…), you’re going to get a pop-up stating that you can only install VMware Tools inside a virtual machine. DO NOT dismiss this pop-up just yet.

  1. Go to Start > Run and type in %TEMP% , the press Enter.
  2. Look for a folder that follows this naming convention {VVVVVVVV-WWWW-XXXX-YYYY-ZZZZZZZZZZZZZ} followed by “-setup” appended to it and open it.

    Open this folder and copy the 3 files out of it to your desktop.
  3. Copy the following 3 files to a folder on your desktop: vcredist_x64.exe, vcredist_x86.exe, and VMware Tools64.msi

    3 Required Files to Copy
  4. Once you’ve saved the files somewhere else, you can now dismiss the popup and exit the VMware Tools installer.

Microsoft Orca

Microsoft Orca is a database table editor that can be used for creating and editing Windows installer packages. We’re going to be using it to update the VMware Tools MSI file we just extracted in the previous steps, to allow it to be installed within a Hyper-V virtual machine.

Orca is part of the Windows SDK that can be downloaded from Microsoft (https://bit.ly/3d7aWoZ). Download the installer, and not the ISO (it’s easier to get exactly what you want this way).

Run the installer and when you get to the screen where you’ll need to Select the features you want to install, select only MSI tools and complete the installation.

After installation is completed, you can search your start menu for “orca” or browse to where it was installed to and launch Orca.

Edit VMware Tools MSI with Orca

Now that we’ve got the necessary files we need, and Orca installed, we’re going to need to edit the VMware Tools MSI to remove an installer pre-check that prevents installation on any other platform than vSphere.

  1. Launch Orca
  2. Click Open, and browse to where you saved VMware Tools64.msi, select it, and click Open.

    Launch Orca and Open VMware Tools MSI
  3. In the left window pane labeled Tables, scroll down and click on InstallUISequence.
  4. In the right window pane, look for the line that says VM_CheckRequirements. Right-click on this entry, and select Drop Row.

    InstallUISequence srcset= VM_CheckRequirements > Drop Row”>
  5. Click save on the toolbar, and close the MSI file. You can also exit Orca now.

What next?

I’ve made you read all the way down to here to tell you that if you want to skip the previous steps and are looking to do this for vSphere 6.7, I have a copy of the MSI that is ready for installation on a Hyper-V virtual machine. If you need it, send me a message on Twitter: @eugenejtorres

Now that you’ve got an unrestricted copy of the VMware Tools MSI package. Copy the VMware Tools MSI along with the vc_redist(x86/x64) installers to your target Hyper-V VMs (or a network share they can all reach), and start installing.

Important: When installing VMware Tools on the Hyper-V virtual machine, you may get the following error:

If you receive the error above, it means you’re missing Microsoft Visual C++ 2017 Redistributable (x64) on that VM.

If this is the case, click cancel and exit the VMware Tools installer. Run the vcredist_x64.exe installer that you copied earlier, and then retry the VMware Tools Installer.

Demo

Since you’ve gotten this far, the next step is to test to validate the procedure. Take a look at the video below to see what migration via Zerto looks like after you’ve taken the steps above.

If you have any questions or found this helpful, please comment. If you know someone that needs to see this, please share and socialize! Thanks for reading!

Share This:

Zerto Automation with PowerShell and REST APIs

Zerto is simple to install and simple to use, but it gets better with automation!  While performing tasks within the UI can quickly become second nature, you can quickly find yourself spending a lot of time repeating the same tasks over and over again.  I get it, repetition builds memory, but it gets old.  As your environment grows, so does the amount of time it takes to do things manually.  Why do things manually when there are better ways to spend your time?

Zerto provides great documentation for automation via PowerShell and REST APIs, along with Zerto Cmdlets that you can download and install to add-on to  PowerShell to be able to do more from the CLI.  One of my favorite things is that the team has provided functional sample scripts that are pretty much ready to go; so you don’t have to develop them for common tasks, including:

  • Querying and Reporting
  • Automating Deployment
  • Automating VM Protection (including vRealize Orchestrator)
  • Bulk Edits to VPGs or even NIC settings, including Re-IP and PortGroup changes
  • Offsite Cloning

For automated failover testing, Zerto includes an Orchestrator for vSphere, which I will cover in a separate set of posts.

To get started with PowerShell and RESTful APIs, head over to the Technical Documentation section of My Zerto and download the Zerto PowerShell Cmdlets (requires MyZerto Login) and the following guides to get started, and stay tuned for future posts where I try these scripts out and offer a little insight to how to run them, and also learn how I’ve used them!

  • Rest APIs Online Help – Zerto Virtual Replication
    • The REST APIs provide a way to automate many DR related tasks without having to use the Zerto UI.
  • REST API Reference Guide – Zerto Virtual Replication
    • This guide will help you understand how to use the ZVR RESTful APIs.
  • REST API Reference Guide – Zerto Cloud Manager
    • This guide explains how to use the ZCM RESTful APIs.
  • PowerShell Cmdlets Guide – Zerto Virtual Replication
    • Installation and use guide for the ZVR Windows PowerShell cmdlets.
  • White Paper – Automating Zerto Virtual Replication with PowerShell and REST APIs
    • This document includes an overview of how to use ZVR REST APIs with PowerShell to automate your virtual infrastructure.  This is the document that also includes several functional scripts that take the hard work out of everyday tasks.

If you’ve automated ZVR using PowerShell or REST APIs, I’d like to hear how you’re using it and how it’s changed your overall BCDR strategy.

I myself am still getting started with automating ZVR, but am really excited to share my experiences, and hopefully, help others along the way!  In fact, I’ve already been working with bulk VRA deployment, so check back or follow me on twitter @EugeneJTorres for updates!

Share This:

ESXi 6.0 U2 Host Isolation Following Storage Rescan

Following an upgrade to ESXi 6.0 U2, this particular issue has popped up a few times, and while we still have a case open with VMware support in an attempt to understand root cause, we have found a successful workaround that doesn’t require any downtime for the running workloads or the host in question.  This issue doesn’t discriminate between iSCSI or Fibre Channel storage, as we’ve seen it in both instances (SolidFire – iSCSI, IBM SVC – FC).  One common theme with where we are seeing this problem is that it is happening in clusters with 10 or more hosts, and many datastores.  It may also be helpful to know that we have two datastores that are shared between multiple clusters.  These datastores are for syslogs and ISOs/Templates.

 

Note: In order to perform the steps in this how-to, you will need to already
have SSH running and available on the host, or access to the DCUI.

Observations

  • Following a host or cluster storage rescan, an ESXi host(s) stops responding in vCenter and still has running VMs on it (host isolation)
  • Attempts to reconnect the host via vCenter doesn’t work
  • Direct client connection (thick client) to host doesn’t work
  • Attempts to run services.sh from the CLI causes script to hang after “running sfcbd-watchdog stop“.  The last thing on the screen is “Exclusive access granted.”
  • The /var/log/vmkernel.log displays the following at this point: “Alert: hostd detected to be non-responsive

Troubleshooting

The following troubleshooting steps were obtained from VMware KB Article 1003409

  1. Verify the host is powered on.
  2. Attempt to reconnect the host in vCenter
  3. Verify that the ESXi host is able to respond back to vCenter at the correct IP address and vice versa.
  4. Verify that network connectivity exists from vCenter to the ESXi host’s management IP or FQDN
  5. Verify that port 903 TCP/UDP is open between the vCenter and the ESXi host
  6. Try to restart the ESXi management agents via DCUI or SSH to see if it resolves the issue
  7. Verify if the hostd process has stopped responding on the affected host.
  8. verify if the vpxa agent has stopped responding on the affected host.
  9. Verify if the host has experienced a PSOD (Purple Screen of Death).
  10. Verify if there is an underlying storage connectivity (or other storage-related) issue.

Following these troubleshooting steps left me at step 7, where I was able to determine if hostd was responding on the host.  The vmkernel.log further supports this observation.

Resolution/Workaround Steps

These are the steps I’ve taken to remedy the problem without having to take the VMs down or reboot the host:

  1. Since the hostd service is not responding, the first thing to do is run /etc/init.d/hostd restart from a second SSH session window (leaving the first one with the hung services.sh restart script process).
  2. While running the hostd restart command, the hung session will update, and produce the following:

  3. When you see that message, press enter to be returned to the shell prompt.
  4. Now run /etc/init.d/vpxa restart, which is the vCenter Agent on the host.
  5. After that completes, re-run services.sh restart and this time it should run all the way through successfully.
  6. Once services are all restarted, return to the vSphere Web Client and refresh the screen.  You should now see the host is back to being managed, and is no longer disconnected.
  7. At this point, you can either leave the host running as-is, or put it into maintenance mode (vMotion all VMs off).  Export the log bundle if you’d like VMware support to help analyze root cause.

 

I hope you find this useful, and if you do, please comment and share!

Share This:

Zerto: ZVM Installation

Here we go!  The following procedure is a step-by-step installation of Zerto Virtual Replication 4.5 U3.  Before starting, you should have built 2 Windows VMs per the Zerto system requirements.  If this is being done in production, be sure to size the servers as needed for the number of VMs you will be protecting.

The version being installed is 4.5 U3.

System Requirements

Note: Be aware of OS limitations when dealing with 32-bit vs 64-bit.  In a 32-bit Windows Server installation, the maximum amount of RAM you can give the system (that it can actually use) is 4GB.  If you’re using Windows Server 2008 R2 or Windows Server 2012, they’re only available in 64-bit, so you won’t need to worry about this limitation.  For more information on Windows memory limitations, please see this.

Now we’ve got that out of the way, here are the system requirements for the Zerto Virtual Manager as of version 4.5 U3:

For the ZVM at Each Site

  • VMware vCenter 4.o U1 or later with at least 1 ESXi host
  • The account you log into the ZVM with and use to run the service will need to have administrative privileges in vCenter.
  • Supported Windows Operating Systems:
    • Windows Server 2003 SP2 or higher
    • Windows Server 2008
    • Windows Server 2008 R2
    • Windows Server 2012
    • Windows Server 2012 R2
  • Resource Reservations in vSphere
    • CPU: Reserve at least 2 vCPUs
    • Memory: Reserve at least 4GB
  • Resource Requirements for ZVMs:
    • Up to 750  protected VMs and up to 5 peer sites:
      • 2 vCPU, 4GB RAM
    • 751-2000 protected VMs and up to 15 peer sites:
      • 4 vCPU, 4GB RAM
    • > 2000 protected VMs and > 15 peer sites:
      • 8 vCPU, 8GB RAM
  • Time/NTP Requirements:
    • Zerto VMs must be synchronized with UTC (you can set actual timezones)
    • It is recommended to use an NTP server for clock synchronization.
  • Microsoft .NET Framework 4 (included with the Zerto installation package)
  • Storage: At least 2GB, plus 1.8GB if you need to install the .NET Framework

For the ZRA on Each Host

One VRA should be installed per host in a participating cluster.  By doing this, you are accounting for any vMotion or DRS activity related to any protected VM in the cluster(s).  ZRAs are deployed from within the Zerto UI, and furthermore, when this is done, DRS affinity rules are automatically created for the ZRAs, and any reservations required are automatically created.

Important:  After deployment of the ZRAs, be sure to add the ZVM and ZRAs into a folder in vCenter that can be excluded from any snapshots.  In otherwords, if you’re using VADP for backups, be sure to exclude this folder, or each ZRA/ZVM from within your backup software.  Failing to do so will cause corruption and you will have to re-deploy the ZRAs.  Furthermore, this will prevent any performance degradation that is a result of snapshot cleanup/consolidation jobs.

ZRAs require the following resources:

  • 12.5GB of datastore space (per ZRA)
  • At least 1GB RAM (reserved automatically through deployment process)
  • ESX/ESXi 4.0 U1 or higher
  • Ports 22 and 443 open on each host during installation of the ZRA (During ZRA deployment, Zerto will also attempt to enable the SSH service on each host, however, if it fails, you will need to manually enable/disable).
  • You’ll need to identify what datastore to install the ZRA to.
  • Static IP Address for each ZRA (recommended to use static)
    • IP Address (f0r each ZRA)
    • Subnet Mask
    • Default Gateway

ZRAs will automatically be named by Zerto during deployment, and clearly indicate what host they are running on.

Network Requirements

  • > 5MB/s is required for Zerto

ZVM Installation

Once you’ve built your Windows VMs to house the ZVM, the steps below will guide you through the installation.  This will need to be done in both sites, although, if you only have 1 site, you can still protect and recover within the same site.  Please note that if you are installing in 2 geographically separated sites, you may need to open some firewall ports before pairing sites and initiating replication.  For firewall requirements, see this document.

  1. Browse to the directory where you have downloaded the installation files to and run the installer (Zerto Virtual Replication VMware Installer).zerto_installation_files
  2. Click Next on the welcome screen.zerto_installation_1_2
  3.  Accept the License Agreement, and click Next.zerto_installation_1_3
  4. Select the installation directory, and click Next.zerto_installation_1_4
  5. Select the installation type, and click Next.zerto_installation_1_5
  6. Select either “Local System Account” or “This Account” if you have a dedicated service account.  Either way you decide to go, the account will require unrestricted access to the local resources on the ZVM.  After you made your selection, click Next.zerto_installation_1_6
  7. In the Database Type dialog box, select your database type, and click Next.Notes:  It is recommended to use an external SQL server when a site has more than 40 hosts that have VMs that need to be protected, and the site has more than 400 VMs that need to be protected.  If you use Windows Authentication for the SQL server (external), then the creadentials in step 6 will be used.zerto_installation_1_7
  8. Enter the name of the vCenter along with the admin credentials that will be used to connect, then click Next.zerto_installation_1_8
  9. Optional: If you have vCloud Director and want to protect it using Zerto Virtual Replication, enter the information necessary to connect to it, and click Next; otherwise, leave the “Enable vCD BC/DR” box unchecked, and click Next.zerto_installation_1_9
  10. Enter the Zerto Virtual Manager settings to identify this installation, and click Next.zerto_installation_1_10
  11. Enter the required information for ZVM communication, and click Next.  The ports listed below are defaults, and if you recover to a site managed by a Cloud Service Provider, be sure you do not change the default ports.zerto_installation_1_11
  12. As soon as you click Next on the screen in the previous step, the installer will auto-validate ZVM communication to ensure the ports to this ZVM are opened, it will verify vCenter credentials that you specified, and will register the vCenter plug-in.If the validation for each item results in “OK”, click Run, otherwise, resolve any errors, and click Recheck.zerto_installation_1_12
  13. If you clicked Run, Zerto Virtual Replication will begin installation and the configuration of components.zerto_installation_1_13
Share This:

The Much Anticipated vSphere 6.5!

Well, this just made my day, and I am really looking forward to getting my hands on it – :::Drumroll:::

At VMWorld Barcelona 2016, it has been announced that vSphere 6.5 will be available as early as Q4 2016!

Some key takeaways include:

  • UEFI Support for AutoDeploy
  • vCenter Server Appliance Migration Tool, allowing migration from a Windows to VCSA to become an included feature.
  • REST-based APIs for VM Management
  • HTML5-based vSphere Client (fully supported)
  • VM-level disk encryption
  • Encrypted vMotion
  • Audit-quality Logging
  • vSphere Integrated Containers
  • More!

Get the details here!

 

Share This:

SRM 6.1 POC Update – Post Failed PSC Remediation

Just an update here to show that after resolving that PSC synchronization issue in our environment, I am now able to successfully pair the two SRM sites in our POC.

Since I have replaced the failed PSC with a new one (new name/IP), and the SRM server was initially connected to the old PSC, I had to first modify the SRM installation and update the PSC it was pointed at. Once I did that, site pairing was successful, and all those SSL and user/password errors I was getting went away.

srm_poc_update_post_pscfix

So, my advice if you run into the same issues as I did – is not to count other systems in the environment out, otherwise, you may be thrown for a loop and support would be no help.

If we hadn’t discovered that synchronization issue between external PSCs, this would have likely been an ongoing issue and it would have seemed like there was no light at the end of the tunnel.

For a recap of the issues seen with site pairing due to the PSC synchronization being broken, see this blog entry.

Share This:

Replace a Failed External PSC in Enhanced Linked Mode: Part 2

In Part 1 of “Replace a Failed External PSC in Enhanced Linked Mode”, I worked through repointing a Windows vCenter Server to another External PSC, in an effort to unregister, and rebuild a failed PSC.

In this guide, I will walk through:

  • Building a new Windows external PSC
  • Joining the SSO Domain
  • Re-pointing VC1 back to this newly-built, and linked external PSC, therefore, returning us to the original topology we started with (except for the server name)

The main systems I’ll be working with in this guide are:

  • VC1 (Windows vCenter that was re-pointed to working PSC for other site while we rebuild it’s home PSC)
  • PSC3 – This is a newly built Windows Server 2012 R2 PSC that is taking the place of PSC1.

I would have chosen to use the same name of the original PSC, but from experience, it’s always better to be safe, and not try to re-introduce a problematic record into the environment, just in case there are still entries hanging out somewhere in the working configuration.

At the end of this guide, we will end up with this topology:

replace_psc_part2_topology_1

 

Install the External PSC Role on the New Server


Note: 
These steps are the same ones to deploy the second PSC in “Deploying Windows vCenter with External PSCs in Enhanced Linked Mode: Part 2.”

  1. Launch the vCenter Server Installer
  2. Select vCenter Server for Windows, and click Install.
  3. Click Next on the welcome screen.
  4. Accept the EULA, click Next.
  5. Under External Deployment, select Platform Services Controller, and click Next.replace_psc_part2_1_5
  6. Verify the system name (This should be the same FQDN of the PSC you are building to replace the failed one), and click Next.
  7. Select Join a vCenter Single Sign-On domain.
  8. Enter the FQDN for the first Platform Services Controller that owns the SSO domain you want to join.
  9. Enter the vCenter Single Sign-On password, then click Next.replace_psc_part2_1_9
  10. When prompted for Certificate Validation, click OK to accept the self-signed certificate.
  11. Select Join an existing site, choose the site from the dropdown menu(should match the site name of the first PSC you created), and click Next.replace_psc_part2_1_11
  12. On the Configure Ports page, make any changes necessary for your environment, and click Next.
  13. Set the PSC installation and data directories, and click Next.
  14. Select whether or not to join the Customer Experience Improvement Program (CEIP), and click Next.
  15. Verify the installation summary settings, and if all looks well, click Install.
  16. Once the installation has completed, log into the vSphere Web Client, and navigate to Home > Administration > Deployment > System Configuration.  Under the Nodes object, verify that there are now 4 nodes (you should see 2 PSCs, and 2 vCenter servers).

 

Next Steps:

After verifying functionality of the newly added PSC, the next step is to re-point VC1 (repointed previously to PSC2) to the new PSC (PSC3).

replace_psc_part2_2_main

Repoint the Connections Between vCenter Server and Platform Services Controller:
 
  1. Log onto the vCenter Server instance (VC1).
  2. In the command prompt (run as administrator), navigate to C:\Program Files\VMware\vCenter Server\bin (or wherever you have vCenter installed to).
  3. Run the cmsso-util script:
    cmsso-util repoint --repoint-psc psc_fqdn_or_static_ip [--dc-port port_number]

    psc_fqdn_or_static_ip – is the FQDN or static IP address of the PSC you want to repoint to.

    replace_psc_part2_3_3

  4. Log into the vCenter Server instance by using the vSphere Web Client to verify that the vCenter server is running and can be managed.
  5. Finally, to see what PSC each vCenter is connected to:
    1. Log into the vSphere Web Client, and navigate to Hosts and Clusters View.
    2. Select a vCenter, and go to the Manage Tab.
    3. In Settings, go to Advanced Settings.
    4. Search for the config.vpxd.sso.admin.uri
    5. When the result is returned, look at the Value field, and this will tell you what PSC the particular vCenter is connected to.replace_psc_part2_3_5

 

This completes the series for Replacing a Failed External PSC in Enhanced Linked Mode. If you find that this has helped you, please feel free to share the information. It took me quite a while to gather all the information needed, and build the environment for this, so I really hope it helps.

In my research when first encountering the issues with my failed PSC, I found that there are a lot of other bloggers out there who have written something about the issues, troubleshooting steps, and fixes related to a failed PSC. While this is not a “one fix to rule them all” solution, it is a very clean way to replace a failed PSC. I apologize for not documenting the same thing for the VCSA, however, if you follow the steps in the order I provided, the links I have in my posts also have the proper steps to execute for the VCSA.

 

Share This:

Replace a Failed External PSC in Enhanced Linked Mode: Part 1

If you’ve followed along starting with the 2-part series about “Deploying Windows vCenter with External PSCs in Enhanced Linked Mode…”, this is the next installment, in which we will go through replacing a failed external PSC using that same topology.

If you haven’t followed along, then the following links will help set the stage for what we’re doing here:

The reasons I’m performing these steps, or even trying it, are:
  • I have never performed this procedure before.
  • I would like to know how to do this and be able to help others out by sharing my experience and the information.
  • I would like to understand the requirements and general order of operations for performing the procedure.
  • I would like to address a current production issue without experimenting in production, and therefore causing further complications or a causing a complete loss of manageability of my environment.

 

The Workflow

replace_psc_part1_topology

 

Lab Testing

 

So to prepare for this in the lab, I’ve created a datacenter in each vCenter, assigned some permissions to both of them (AD-integrated permissions), and licensed both vCenters (licenses to be removed following the testing).  This was done to ensure that replication was succeeding between the two PSCs.  I also ran the vdcrepadmin.exe utility on both PSCs to ensure replication is succeeding, and there are no outstanding changes or replication problems.

From PSC1:

.\vdcrepadmin.exe -f showpartnerstatus -h localhost -u administrator -w [password]

replace_psc_part1_lab_1_1
From PSC2:
.\vdcrepadmin.exe -f showpartnerstatus -h localhost -u administrator -w [password]
replace_psc_part1_lab_1_2
The next step for me to do is shutdown PSC1 to simulate a failure.  Once shut down, re-point the vCenter affected by this failure to the working PSC:
replace_psc_part1_lab_1_3

If I run the following on PSC2, it will show that PSC1 is now offline:

.\vdcrepadmin -f showpartnerstatus -h localhost -u administrator -w [password]

If I run the following on PSC2, it still shows that there are two PSCs registered:

.\vdcrepadmin -f showservers -h localhost -u administrator -w [password]

replace_psc_part1_lab_1_4

Re-point the Connections Between vCenter Server and Platform Services Controller

  1. Log onto the vCenter Server instance (VC that is still connected to the failed PSC).
  2. In the command prompt (run as administrator), navigate to C:\Program Files\VMware\vCenter Server\bin (or wherever you have vCenter installed to).
  3. Run the cmsso-util script to repoint the connection of this vCenter to the PSC that is still alive:
    cmsso-util repoint --repoint-psc psc_fqdn_or_static_ip

    (Running the command above may take some time to complete. In my test lab, it took approximately 13 minutes to complete)

    replace_psc_part1_lab_3_3

    Part of the repointing task includes stopping and starting all vCenter related services on the server.  Give the web server additional time to fully initialize before moving on with the next step.

  4. Log into the vCenter Server instance by using the vSphere Web Client to verify that the vCenter server is running and can be managed.After the web server completed its initialization for VC1, I was able to log in successfully, and verify the inventory, permissions, and licensing.  The next step is to Unregister the bad PSC (PSC1) from the configuration on PSC2.

 

Unregister the Failed PSC

 

  1. On the PSC (live one that you just repointed to), open a command prompt (run as administrator).
  2. Browse to C:\ProgramData\VMware\vCenterServer\cfg\install-defaults.
  3. On the failed PSC: Open the vmdir.ldu-guid file to find the hostid.
  4. On the working PSC: Navigate to C:\Program Files\VMware\vCenter Server\bin
  5. On the working PSC: Run the cmsso-util unregister command to unregister the stopped/failed Platform Services Controller:

    cmsso-util unregister --hostId host_Id --node-pnid Platform_Services_Controller_System_Name --username administrator@vsphere.local --passwd [password]

    replace_psc_part1_lab_4_5

    After this has been run successfully, verify that the OLD PSC has been removed from the topology.

  6. n the vSphere Web Client, navigate to Home > Administration > Deployment > System Configuration.  Under the Nodes object, verify that there are only 3 nodes (you should see 1 PSC, and 2 vCenter servers).
  7. On PSC2, run

    .\vdcrepadmin -f showservers -h localhost -u administrator -w ************

    replace_psc_part1_lab_4_7

    You should now only see one server in the listing, as opposed to 2, since you just removed the failed PSC.

  8. Delete the failed PSC (VM) you no longer need from the vSphere inventory.

 

There you have it.  We have successfully re-pointed a vCenter to another PSC, unregistered the bad PSC, and validated that we are now ready to rebuild in order to re-instate the original topology.  The next part to this series will cover building the replacement PSC, joining the SSO domain, and finally, repointing the vCenter at this new PSC, therefore returning the topology to where it was before we started.

Share This:

Deploying Windows vCenter with External PSCs in Enhanced Linked Mode: Part 2

Before following any steps in here, be sure to refer to the previous part to this series, which will provide some background information and walk through the steps to install the first PSC and vCenter servers.  The steps contained in this post will be a continuation, marking the differences between the initial install (previous post), and the additional PSC and vCenter server.
In this post, I will be walking through joining the second PSC to the SSO domain created previously.  Following that, if there are any steps different for the subsequent vCenter Server installation, I will call out any steps in this installation that differ from the first install and include screenshots.
For any pre-requisites, head to Part 1 of this series.

 

Install the Second Platform Services Controller on a Windows Machine and Joining the SSO Domain

If deploying in a production environment, refer to the vSphere Installation and Setup for vSphere 6.0 Guide.

    1. Launch the vCenter Server Installer
    2. Select vCenter Server for Windows, and click Install.
    3. Click Next on the welcome screen.
    4. Accept the EULA, click Next.
    5. Under External Deployment, select Platform Services Controller, and click Next.external_psc_part2_1_5
    6. Verify the system name (recommended you use FQDN, not IP Address), and click Next.
    7. Select Join a vCenter Single Sign-On domain.
    8. Enter the FQDN for the first Platform Services Controller that owns the SSO domain you want to join.
    9. Enter the vCenter Single Sign-On password, then click Next.external_psc_part2_1_9
    10. When prompted for Certificate Validation, click OK to accept the self-signed certificate.
    11. Select Join an existing site, choose the site from the drop-down menu (should match the site name of the first PSC you created), and click Next.external_psc_part2_1_11
    12. On the Configure Ports page, make any changes necessary for your environment, and click Next.
    13. Set the PSC installation and data directories, and click Next.
    14. Select whether or not to join the Customer Experience Improvement Program (CEIP), and click Next.
    15. Verify the installation summary settings, and if all looks well, click Install.

Next Steps

 
Once completed, run the installer on the vCenter Server that will connect to this PSC, and be sure to connect it to THIS PSC, NOT THE FIRST PSC that was built.

external_psc_part2_1_ns_1

Install vCenter Server and the vCenter Server Components, Connecting to the Second PSC

Perform these steps, making sure to connect this vCenter to the PSC that was just installed above, not the first PSC from Part 1.
Installation
 
  1. Launch the vCenter installer and select vCenter Server for Windows. Click Install.
  2. Once the installer initializes, click Next.
  3. Accept the VMware End User License Agreement, and click Next.
  4. Under External Deployment, select vCenter Server and click Next.
  5. Enter the system’s FQDN, and click Next.
  6. Enter the information for the external PSC that was deployed in the section above, and click Next.  This step will register the vCenter with the PSC.
  7. When prompted for certificate validation, click OK to approve the self-signed certificate created by the PSC.
  8. Configure the vCenter service account according to your environment requirements and click Next.  If you are using an external database server, you will need to specify a user service account.

    Note: 
    If you are using a user service account, you will need to make sure it has the “log on as a service” privilege in the local security policy.

  9. Select your database deployment and enter information if necessary, then click Next.
  10. Configure the required ports if necessary to match your environment, and click Next.
  11. Configure the installation directory for the vCenter Server and data, then click Next.
  12. Review all settings, and when ready, click Install.
Next Steps
 
After you’ve completed this setup, you should now have a functional topology, with 2 vCenters each connected to an external platform services controller.  The two external PSCs should now also be running in enhanced linked mode, and to verify, you can log into either vCenter, and see that you can also manage the inventory of the other.
I will follow this up with my testing for vCenter repointing and recovering from a failed PSC in this topology.
Share This:

Deploying Windows vCenter with External PSCs in Enhanced Linked Mode: Part 1

In many cases for small environments, it makes sense to deploy a vCenter Appliance with an embedded Platform Services Controller.  In larger environments with multiple sites, although you can (doesn’t mean you should) manage remote hosts with a single vCenter, it may make more sense to deploy a vCenter in each site, or region to further increase availability.  Furthermore, by configuring Enhanced Linked Mode, you can make management simpler by being able to link vCenter systems and replicate roles, permissions, licenses, policies, and tags; instead of having vCenter servers which are all managed individually.

Enhanced Linked Mode not only allows you to connect Windows vCenters, or just vCenter Server appliances; you can have an environment where Windows vCenters as well as vCenter Appliances can be linked together.  That said – there are supported and unsupported topologies, which is beyond the scope of this, however, you can find the information for those topologies in this VMware KB Article.

The following procedure is my re-creation of our production topology in a test environment.  The steps will walk through standard installation and configuration of the vCenter servers and PSCs in Enhanced Linked mode to get a to a usable state.  The follow-up post to this will be related to Installing the second PSC and vCenter, linking to the SSO domain and site created in this how-to.

Disclaimer:  The following information and procedures are performed in an isolated environment, and I am building these with the absolute minimum requirements since my test environment is a single physical host that also hosts other test machines in use by another engineer.  If performing these steps in production, be sure to follow proper sizing best practices, and built to suit your particular environment using the resource links provided throughout the article.

Hardware Requirements: vCenter Server for Windows

Before we get into the installation procedure, here’s an idea of what I’m building and the topology I will be using.

(All servers listed below are running Windows Server 2012 R2)

  • 1 Active Directory Domain Controller
  • 1 Single Sign-On Domain
  • 2 Sites (simulated)
  • 2 External Platform Services Controllers (one for each site)
  • 2 vCenter Servers (one for each site)

external_psc_diagram_1

 

Install a Platform Services Controller on a Windows Host

 

If deploying in a production environment, refer to the vSphere Installation and Setup for vSphere 6.0 Guide.
Pre-requisites
  • Verify system meets the minimum HW/SW requirements
  • Download the vCenter Server Installer
  • Install Adobe Flash Player version 11.9 or later if you will be running using the vSphere Web Client from one of the host machines.
  • Forward and Reverse DNS entries should be created for each system prior to installation.

 

Installation

  1. Launch the vCenter installer and select vCenter Server for Windows. Click Install.

    external_psc_part1_1_1

  2. Once the installer initializes, click Next.
  3. Accept the VMware End User License Agreement, and click Next.

    external_psc_part1_1_3

  4. Under External Deployment, select Platform Services Controller and click Next.

    external_psc_part1_1_4

  5. Enter the system’s FQDN, and click Next.

    external_psc_part1_1_5

  6. If this is the first PSC being created, create a new Single Sign-On Domain, set the password, provide the site name, and click Next.

    external_psc_part1_1_6

  7. Configure the ports as needed (I left this at the defaults, as I have no need to change them), then click Next.

    external_psc_part1_1_7

  8. Change the installation and data directories as needed and click Next.  For my implementation, I kept the defaults, since this is not production.

    external_psc_part1_1_8

  9. Select whether or not you want to join the customer experience improvement program (CEIP), then click Next. Since this is an isolated environment with no external internet access, I unchecked it.

    external_psc_part1_1_9

  10. At the Ready to Install screen, verify settings, and if everything looks good, click Install.  When done, the installer will provide you with next steps (convenient!)

    external_psc_part1_1_10

 

Next Steps
 
Note: You must wait for the PSC installation to complete before moving to the next step.  VMware does not support concurrent installations of PSC and vCenter.

 

Install vCenter and the vCenter Components

 

  1. Launch the vCenter installer and select vCenter Server for Windows, then click Install.

    external_psc_part1_2_1

  2. Once the installer initializes, click Next.
  3. Accept the VMware End User License Agreement, and click Next.

    external_psc_part1_2_3

  4. Under External Deployment, select vCenter Server and click Next.

    external_psc_part1_2_4

  5. Enter the system’s FQDN, and click Next.

    external_psc_part1_2_5

  6. Enter the information for the external PSC that was deployed in the section above, and click Next.  This step will register the vCenter with the PSC.

    external_psc_part1_2_6

  7. When prompted for certificate validation, click OK to approve the self-signed certificate created by the PSC

    external_psc_part1_2_7

  8. Configure the vCenter service account according to your environment requirements and click Next.  If you are using an external database server, you will need to specify a user service account.

    Note: If you are using a user service account, you will need to make sure it has the “log on as a service” privilege in the local security policy.

    external_psc_part1_2_8

  9. Select your database deployment and enter information if necessary, then click Next.

    external_psc_part1_2_9

  10. Configure the required ports if necessary to match your environment, and click Next.

    external_psc_part1_2_10

  11. Configure the installation directory for the vCenter Server and data, then click Next.

    external_psc_part1_2_11

  12. Review all settings, and when ready, click Install.

    external_psc_part1_2_12

 

Next Steps
  • Configure vCenter to integrate with your Active Domain or LDAP server as needed.
  • Configure any group memberships, roles, permissions, licenses, etc…
  • Install the next PSC and be sure to join the existing Single Sign-On domain that you just created.  Following that, install the next vCenter, and you are done!
Share This: