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.
Category Archives: Uptime
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).
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.
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
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.
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.
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().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:
Once you know that you know which plan you want to run the report on and you know whether to pass a  or a  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:
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.
Recently 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
Today we’ll take a look at running a recovery plan for SRM programatically, from the API via PowerCLI.
In almost all scenarios, falling over in an automated fashion is a poor idea. There is a lot of risk associated with it and a lot of potential liability for failing over due to incorrect reasoning. Failing over automatically in *test mode* however makes an awful lot of sense!
Recently I posted about the new PowerCLI 5.5R2 capability to interact with the SRM API, and I want to write a few posts on using those capabilities to automate some typical (and perhaps some atypical) activities one might wish to accomplish. In the next few posts I’ll be showing some of the things you can do like:
- How the SRM API is structured and how to access it through PowerCLI
- Walk through the examples given in the documentation
- How to generate reports
- How to add VMs to existing protection groups
- How to automate test failovers
I am not a PowerCLI genius, so there is a good chance these scripts will not be the most elegant approach you could take, but hopefully this will give you an idea of what’s possible to do with this interaction.
First, let’s take a look at how we actually go about accessing the SRM API through PowerCLI.
VMware vSphere Data Protection (VDP) Advanced features the ability to replicate backup data between VDP Advanced appliances. This is a very useful method for moving backup data offsite. Backup data replication is also easier, more efficient, more secure, and less expensive than using tape to move backup data offsite.
VDP Advanced supports various replication topologies: one-to-one, many-to-one, and one-to-many. The next question I often get is “Do I have to buy VDP Advanced licenses for the target appliance?”. The answer is, it depends…