Home > Blogs > VMware vSphere Blog > Category Archives: Uptime

Category Archives: Uptime

SRM install error: Failed to Clear Inventory Service Registration

If you see this message during an SRM 5.8 upgrade, chances are you are doing what is a moderately rare type of an SRM install that has caused you some problems.

The given scenario that will lead to this situation:

  • You had a previous SRM install
  • You uninstalled SRM but left the old SRM database in place
  • You have installed a new vCenter and inventory service (or simply wiped and refreshed the inventory service database itself)
  • You are installing a new SRM instance
  • You chose to overwrite the SRM database as part of the new install

This was the scenario that brought me to run into the error “failed to clear inventory service registration” at the end of the SRM install.  Retrying does nothing, and the only option is to cancel the install and roll back.

So why is this?

SRM tries to handle inventory service registration intelligently; in this case since it has found an existing database, the assumption is that you have re-installed SRM, but it knows nothing about the vCenter/IS components.  SRM stores its UUID in its database, and then registers to inventory services with that UUID.  If you were to reinstall SRM, the old UUID registered to IS would no longer be valid, so during our current situation it tries to remove the old registered UUID in order to use the new one with IS, the one it is putting into its new database.

In this scenario, what has happened is that when overwriting the SRM database during the install, SRM has tried to clean up the old SRM registration to Inventory Services by removing the UUID found in the old database.  It does this to avoid conflicting SRM registrations in IS (e.g. if you were simply re-installing SRM alone.)

Since, however, you have a new vCenter and/or a new inventory service, that old UUID is no longer present, and the SRM install fails as it cannot find and unregister the UUID from IS that it finds in the old SRM database.

The solution can be one of two:

  1. Retain the old SRM database instead of overwriting it.  This may lead to some cleanup activities you’ll need to do if you purposefully needed to get rid of the old database information (which presumably is why you were overwriting it in the first place!).
  2. Wipe out the SRM database before doing your install and start with a clean slate, instead of overwriting it.  This is probably the easiest, and given that you were going to overwrite it anyway just takes a few moments up front.

This is likely a rare sort of scenario where you’re starting from scratch with everything but the SRM database. Most likely you’ll come across this in a lab/testbed environment where you run through installs and upgrades on a regular basis.

So not a big deal, but hopefully this helps save someone the time that it took me to find it!

 

vSphere Data Protection Linux File Level Restore

Both editions of VMware vSphere Data Protection – VDP and VDP Advanced – feature the ability to perform a file level restore (FLR) with nothing more than a Flash-enabled web browser. There is no need to install additional backup software, an agent, etc. VMware Tools is required, but this is present in nearly all virtual machines (VMs) by default. FLR works for Windows and Linux VMs. After a moment, you may be thinking that using a web browser is no big deal with Windows – most Windows VMs have at least one web browser installed already – however, that is not the case with Linux VMs. So how can we work around that? Let’s dig in…

Continue reading

Site Recovery Manager 5.8 is now GA – What’s new?

Yesterday VMware announced the GA of Site Recovery Manager 5.8. There are a number of great additions and improvements and I’m going to cover them here briefly.

Full Web Client Integration

SRM-Site-Summary

The most visible change is that SRM 5.8 is fully integrated as a plug-in with the vSphere Web Client. In addition to not having to use two different interfaces to manage your environment improvements were also made to a few workflows making it easier and simpler to map arrays, networks, folders, etc by having SRM handle the reciprocal instead of having to do it manually.

Continue reading

What’s New with vSphere Data Protection 5.8 and vSphere Replication 5.8

Along with all of the announcements at VMworld 2014, I am happy to report on the latest versions of vSphere Data Protection (VDP) and vSphere Replication. As most of you may already know, there are two editions of VDP: VDP, which is included with vSphere Essentials Plus Kit and higher editions, and VDP Advanced, which is purchased separately. vSphere Replication is included with vSphere Essentials Plus Kit and higher editions. This article highlights the most prominent new features and updates in VDP Advanced and vSphere Replication.

Continue reading

vSphere Data Protection (VDP) – SSO server could not be found

I ran into the following error today while working with VDP: The SSO server could not be found. Please make sure the SSO configuration on the VDP appliance is correct. There is a KB article on this: http://kb.vmware.com/kb/2072033. After reading through the article and checking those items, the issue was still not resolved.

Some background info: It is my lab environment, which has a couple of DNS sources. I have vCenter Server running on Windows. The Windows server name was vc01.vmware.local and part of an Active Directory domain named vmware.local. The lab environment “outside” of my vmware.local domain is named pml.local. VDP is using a pml.local DNS server as its primary DNS server and a vmware.local DNS server as its secondary DNS server. I know – kind of crazy and no wonder I was having this issue. I tried a variety of combinations with my vmware.local DNS and the hosts file on the VDP appliance, with no luck. I even renamed my vCenter Server to the host name found in the pml.local DNS and re-registered the VDP appliance to vCenter Server using the new host name. The re-registration went fine, but when I tried to connect using the vSphere Web Client – still, no luck (same error).

The fix:

I logged onto the VDP appliance and ran this: tail -f /usr/local/avamar/var/vdr/server_logs/vdr-server.log

I then tried connecting to the VDP appliance using the vSphere Web Client. I observed the VDP appliance attempting to connect to SSO using the URL https://vc01.vmware.local:7444/sso-adminserver/sdk/vsphere.local . I added an entry in the hosts file on the VDP appliance for vc01.vmware.local and I was able to connect. Even though I renamed my vCenter Server, this did not change the URL for connecting to SSO. I verified this in the Advanced Settings for vCenter Server.

Lessons learned and reinforced:

  • DNS must be rock solid in a VMware environment (this has always been the case) – especially with VDP in the mix. You should be able to resolve host names across the entire environment by short name, fully qualified domain name (FQDN), forward lookup, and reverse lookup.
  • Always use fully qualified domain names when configuring VDP.
  • Time must also be in sync. Not the problem in my case, but just making sure everyone is aware.
  • Renaming vCenter Server (the host name) does not change URLs for connecting to SSO, the VIM API, etc.
  • It is possible to populate the /etc/hosts file in the VDP appliance to work around many name resolution issues, but this is not a recommended practice (see the next bullet point).
  • Keep things simple. In my case, it can’t be helped, but having a single source for name resolution is best.

@jhuntervmware

 

vCenter Server 5.5 Update 1b released

Today VMware released an update to its virtualization management solution, vCenter Server. The update brings several fixes as documented in the release notes which can be reviewed in full here.

The new versions are as follows:

  • vCenter Server 5.5 Update 1b | 12 JUN 2014 | Build 1891313
  • vCenter Server 5.5 Update 1b Installation Package | 12 JUN 2014 | Build 1891310
  • vCenter Server Appliance 5.5 Update 1b | 12 JUN 2014 | Build 1891314
    downloaded now from vmware.com

Continue reading

Understanding vSphere Replication (VR) Scheduling and RPO Violations

One of the most common misunderstandings with vSphere Replication (VR) is how it calculates replication schedules and recovery point objective (RPO) violations. Since this is a common question and one that takes a few moments to answer, I thought it made sense to post it in a blog article. I’ll start with the basics: The replication schedule for a VM is determined by the RPO policy set when configuring replication for that VM. The possible value for RPO can be any number of minutes from 15 minutes to 1440 minutes (24 hours). There is currently no way to schedule replication at specific times. VR generates its own replication schedule internally by considering all replicated VMs on each vSphere host.

Continue reading

vCenter Heartbeat End of Availability

For those of you who have used vCenter Heartbeat to protect your vCenter instances, please be aware that we have announced the end of its availability as of today, June 2 2014.

Don’t worry though if you’re using it today; the current iteration will be supported through late 2018.

What does that mean?  Are we getting away from protecting vCenter?  Not by a long shot.  We have big plans in this space.  vCenter has become a very critical component of the infrastructure and we’re looking at lots of different means by which you can protect it.

What can you do first?  Make sure you’re running it in a virtual machine!  That gives you all the proactive benefits of downtime avoidance with DRS and Storage DRS, and the reactive benefits of automated restart with HA clusters.

As always make sure you have reliable backups (and test your restores!) of vCenter and its database.

Take a look at the official announcement of the end-of-availability and read the details about support and the FAQ, and feel free to ask us at VMware about maximizing your vCenter availability.

Reporting on Site Recovery Manager Failover via PowerCLI

Here’s another fun one!

So we’ve automated some Site Recovery Manager failovers with PowerCLI.  Say we run a weekly test for a given recovery plan.  But now we want to know how it worked.  Maybe generate a table report, maybe email it out, whatever.

Take a look at the following:

I’m assuming you’ve already done the Connect-VIServer and $SrmConnection to the appropriate systems.  What next?  Well as before the $SrmAPI mapping again gives us an entry point to the actual SRM API itself.

$PlanMoref = $SrmApi.Recovery.Listplans()[1].moref 

This is in essence retrieving the managed object reference ID for the recovery plan returned by “Listplans”.  You will need to know which recovery plan you want to report on, but that is easily determined by running the Listplans method without any reference, i.e. simply running:

$SrmApi.Recovery.Listplans

Once you know that you know which plan you want to run the report on and you know whether to pass a [0] or a [1] or whatever to the $PlanMoref variable you are creating.

Once that is done we want to pull out the managed object reference to the *history* of the recovery plan execution.  So we execute the GetHistory method against the $PlanMoref variable we have created, and assign it to the new variable $HistoryMoref.

$HistoryMoref = $SrmApi.Recovery.GetHistory($PlanMoref)

This then attaches us to the history of the particular recovery plan we want, and gives us a nice variable name to use for the next step:

$HistoryMoRef.GetRecoveryResult(1)

This, now, is the heart of the matter.  It is retrieving the data from the latest run of the recovery plan we attached to earlier.  The “1″ listed here indicates the most recent execution of the recovery plan.  If we indicated “2″ it would not retrieve the second most recent, but the last *two* executions, and so forth.  So to retrieve the details of the last run of our recovery plan, we need to know: a) The plan as listed by ListPlans, b) the Moref of the plan as listed by Listplans()[planid].moref, c) to attach to the history using the plan’s GetHistory($PlanMoref), and that we d) access the output by running GetRecoveryResult against all the prior input.

Make sense?  Fundamentally it can be reduced to the 4 or fewer lines, as per my example at the top.  What you do *with* that output is up to you!  If you check out the sample scripts for generating reports against the SRM API, or really reference any PowerCLI materials you’ll doubtless come up with some great ideas for generating tables, reports, emails, whatever is appropriate.

One last thing though – we’ve generated a test run automatically, and now run a report against the result.  What’s next?  Run a cleanup, as per my previous blog about automating execution.

VMware Virtual SAN & vSphere HA Recommendations

VSANRecently I’ve participated in a number of discussions around Virtual SAN and vSphere HA where a couple of great and interesting questions have been brought up with regards to Virtual SAN and vSphere HA interoperability and behavior.

For the most part, the discussions have been around vSphere HA and how it works and supports network partitions and isolation events for Virtual SAN enabled clusters. Those concerns required a bit more detail to provide the adequate technical guidance.

Before diving into the details, let me start with an official statement about Virtual SAN and vSphere HA. vSphere HA fully supports and is integrated with Virtual SAN. This support required some changes in vSphere HA which impact vSphere HA behavior and result in some unique Virtual SAN related configuration considerations for vSphere HA.

In this post I will detail the following information and recommendations:

  • Architecture Changes Impacting Isolation and Partition Support
  • Heartbeat Datastore Recommendations
  • Host Isolation Address Recommendations
  • Isolation Response Recommendations

Continue reading