Changing a VM’s Recovery VRA When a Host Crashes

Yesterday, we had one host in our recovery site PSOD, and that caused all kinds of errors in Zerto, primarily related to VPGs.  In our case, this particular host had both inbound and outbound VPGs attached to it’s VRA, and we were unable to edit (edit button in VPG view was grayed out, along with the “Edit VPG” link when clicking in to the VPG) any of them to recover from the host failure.  Previously when this would happen, we would just delete the VPG(s) and recreate it/them, preserving the disk files as pre-seeded data.

When you have a few of these to re-do, it’s not a big deal, however, when you have 10 or more, it quickly becomes a problem.

One thing that I discovered that I didn’t know was in the product, is that if you click in to the VRA associated with the failed host, and go do the MORE link, there’s an option in there to “Change Recovery VRA.”  This option will allow you to tell Zerto that anything related to this VRA should now be pointed at X. Once I did that, I was able to then edit the VPGs.  I needed to edit the VPGs that were outbound, because they were actually reverse-protected workloads that were missing some configuration details (NIC settings and/or Journal datastore).

Here’s how:

  1. Log on to the Zerto UI.
  2. Once logged on, click on the Setup tab.

  3. In the “VRA Name” column, locate the VRA associated with the failed host, and then click the link (name of VRA) to open the VRA in a new tab in the UI.

  4. Click on the tab at the top that contains VRA: Z-VRA-[hostName].
  5. Once you’re looking at the VRA page, click on the MORE link.

  6. From the MORE menu, click Change VM Recovery VRA.

  7. In the Change VM Recovery VRA dialog, check the box beside the VPG/VM, then select a replacement host. Once all VPGs have been udpated, click Save.

Once you’ve saved your settings, validate that the VPG can be edited, and/or is once again replicating.

 

Share This:
Share

Zerto: Dual NIC ZVM

Something I recently ran into with Zerto (and this can happen for anything else) was the dilemma of being able to protect remote sites that (doesn’t happen often) happen to have IP addresses that are identical in both the protected and recovery sites.  And no, this wasn’t planned for, it was just discovered during my Zerto deployment in what we’ll call the protected sites.

Luckily, our network team had provisioned two new networks that are isolated, and connected to these protected sites via MPLS.  Those two new networks do not have the ability to talk back to our existing enterprise network without firewalls getting involved, and this is by design since we are basically consolidating data centers while absorbing assets and virtual workloads from a recently acquired company.

When I originally installed the ZVM in my site (which we’ll call the recovery site), I had used IP addresses for the ZVM and VRAs that were part of our production network, and not the isolated network set aside for this consolidation.  Note: I installed the Zerto infrastructure in the recovery site ahead of time before discussions about the isolated networks was brought up.  So, because I needed to get this onto the isolated network in order to be able to replicate data from the protected sites to the recovery site, I set out to re-IP the ZVM, and re-IP the VRAs.  Before I could do that, I needed to provide justification for firewall exceptions in order for the ZVM in the recovery site to link to the vCenter, communicate with ESXi hosts for VRA deployment, and also to be able to authenticate the computer, users, service accounts in use on the ZVM.  Oh, and I also needed DNS and time services.

The network and security teams asked if they could NAT the traffic, and my answer was “no” because Zerto doesn’t support replication using NAT.  That was easy, and now the network team had to create firewall exceptions for the ports I needed.

Well,  as expected, they delivered what I needed.  To make a long story short, it all worked, and then about 12 hours before we were scheduled to perform our first VPG move, it all stopped working, and no one knew why.  At this point, it was getting really close to us pulling the plug on the migration the following day, but I was determined to get this going and prevent another delay in the project.

When looking for answers, I contacted my Zerto SE, reached out on twitter, and also contacted Zerto Support.  Well, at the time I was on the phone with support, we couldn’t do anything because communication to the resources I needed was not working.  We couldn’t perform a Zerto re-configure to re-connect to the vCenter, and at this point, I had about 24VPGs that were reporting they were in sync (lucky!), but ZVM to ZVM communication wasn’t working, and recovery site ZVM was not able to communicate with vCenter, so I wouldn’t have been able to perform the cutover.  So since support couldn’t help me out in that instance, I scoured the Zerto KB looking for an alternate way of configuring this where I could get the best of both worlds, and still be able to stay isolated as needed.

I eventually found this KB article that explained that not only is it supported, but it’s also considered a best practice in CSP or large environments to dual-NIC the ZVM to separate management from replication traffic.  I figured, I’m all out of ideas, and the back-and-forth with firewall admins wasn’t getting us anywhere; I might as well give this a go.  While the KB article offers the solution, it doesn’t tell you exactly how to do it, outside of adding a second vNIC to the ZVM.  There were some steps missing, which I figured out within a few minutes of completing the configuration.  Oh, and part of this required me to re-IP the original NIC back to the original IP I used, which was on our production network.  Doing this re-opened the lines of communication to vCenter, ESXi hosts, AD, DNS, SMTP, etc, etc… Now I had to focus on the vNIC that was to be used for all ZVM to ZVM as well as replication traffic.  In a few short minutes, I was able to get communication going the way I needed it, so the final thing I needed to do was re-configure Zerto to use the new vNIC for it’s replication-related activities.  I did that, and while I was able to re-establish the production network communications I needed, now I wasn’t able to access the remote sites (ZVM to ZVM) or access the recovery site VRAs.

It turns out, what I needed here were some static, persistent routes to the remote networks, configured to use the specific interface I created for it.

Here’s how:

The steps I took are below the image.  If the image is too small, consider downloading the PDF here.

zerto_dual_nic_diagram

 

On the ZVM:

  1. Power it down, add 2nd vNIC and set it’s network to the isolated network.  Set the primary vNIC to the production network.
  2. Power it on.  When it’s booted up, log in to Windows, and re-configure the IP address for the primary vNIC.  Reboot to make sure everything comes up successfully now that it is on the correct production network.
  3. After the reboot, edit the IP configuration of the second vNIC (the one on the isolated network).  DO NOT configure a default gateway for it.
  4. Open the Zerto Diagnostics Utility on the ZVM. You’ll find this by opening the start menu and looking for the Zerto Diagnostics Utility.  If you’re on Windows Server 2008 or 2012, you can search for it by clicking the start menu and starting to type “Zerto.”
    zerto_dual_nic_1_4
  5. Once the Zerto Diagnostics Utility loads, select “Reconfigure Zerto Virtual Manager” and click Next.
    zerto_dual_nic_1_5
  6. On the vCenter Server Connectivity screen, make any necessary changes you need to and click Next.  (Note: We’re only after changing the IP address the ZVM uses for replication and ZVM-to-ZVM communication, so in most cases, you can just click Next on this screen.)
  7. On the vCloud Director (vCD) Connectivity screen, make any necessary changes you need to and click Next. (Note: same note in step 6)
  8. On the Zerto Virtual Manager Site Details screen, make any necessary changes you need to  and click Next. (Note: same as note in step 6)
  9. On the Zerto Virtual Manager Communication screen, the only thing to change here is the “IP/Host Name Used by the Zerto User Interface.”  Change this to the IP Address of your vNIC on the isolated Network, then click Next.zerto_dual_nic_1_9
  10. Continue to accept any defaults on following screens, and after validation completes, click Finish, and your changes will be saved.
  11. Once the above step has completed, you will now need to add a persistent, static route to the Windows routing table.  This will tell the ZVM that for any traffic destined for the protected site(s), it will need to send that traffic over the vNIC that is configured for the isolated network.
  12. Use the following route statement from the Windows CLI to create those static routes:
    route ADD [Destination IP] MASK [SubnetMask] [LocalGatewayIP] IF [InterfaceNumberforIsolatedNetworkNIC] -p
    Example:>
    route ADD 192.168.100.0 MASK 255.255.255.0 10.10.10.1 IF 2 -p
    route ADD 102.168.200.0 MASK 255.255.255.0 10.10.10.1 IF 2 -p
    
    Note: To find out what the interface number is for your isolated network vNIC, run route print from the Windows CLI.  It will be listed at the top of what is returned.
    

 

zerto_dual_nic_1_10

Once you’ve configured your route(s), you can test by sending pings to remote site IP addresses that you would normally not be able to see.

After performing all of these steps, my ZVMs are now communicating without issue and replications are all taking place.  A huge difference from hours before when everything looked like it was broken.  The next day, we were able to successfully move our VPGs from protected sites to recovery sites without issue, and reverse protect (which we’re doing for now as a failback option until we can guarantee everything is working as expected).

If this is helpful or you have any questions/suggestions, please comment, and please share! Thanks for reading!

 

Share This:
Share

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:
Share

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:
Share

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:
Share

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:
Share

SRM 6.1 POC Update & PSC Problems

I recently ran into some problems during my first attempt at pairing the two sites in my SRM POC, which resulted in a failure, and some misleading error messages.  Since help on this was pretty scarce on the ‘net, I opened a case with VMware Support.  After about a week’s worth of troubleshooting – repairing the installation, re-installing SRM with a fresh database, and certificate regeneration/registration provided no resolution.

srm_psc_error_1

As I was waiting for an escalation from VMware, we discovered that one of the PSCs in this environment stopped replicating changes to the other. Upon further analysis, I discovered that it had been about a month since that particular platform service controller had stopped replicating changes. What made it tough to find the problem here was that we were still able to get into vCenter and manage it just fine, but taking a peek under the covers proved there was definitely an issue.  It was by chance a license change to vCenter exposed this problem when we saw that the change didn’t make it from one vCenter to the other.

The following command will provide you with the results seen below, which indicate the synchronization problem:

On each PSCrun the following command from the vmdird directory: 

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

Partner: psc1.domain.local
Host available: Yes
Status available: Yes
My last change number: 872590
Partner has seen my change number: 10846
Partner is 861744 changes behind.

Partner: psc2.domain.local
Host available: Yes
Status available: Yes
My last change number: 2147483197
Partner has seen my change number: 2147483197
Partner is 0 changes behind.

 

Since this had been discovered, the support engineer and I agreed that we should put the site recovery pairing on hold until the PSC issue was resolved, just so we didn’t have too many variables involved in our troubleshooting. To make a long story short, the PSC synchronization was the root cause of SRM not being able to pair the sites, and I’ve also written up a series on re-creating the environment in isolation, and performing the PSC replacement to provide the ultimate solution.

Share This:
Share