A question came across my desk a few days ago around being able to automatically back up VMs that have been migrated by vCenter Site Recovery Manager (SRM). After a bit of thought, it seems this is fairly simple to solve. With SRM, I migrate VMs to a resource pool at my recovery site. Why you might ask? This resource pool is configured with shares set to “High”. This has no impact during normal operations, but when I migrate or fail over important workloads, I want to be sure these workloads have priority if there is contention for CPU and memory. However, this also creates a secondary benefit when it comes to backing up migrated VMs…
Category Archives: Uptime
With the release of VMware vSphere Data Protection (VDP) 5.8, a new type or “identity” of VDP appliance was introduced. It is called VDP Replication Target. When deploying previous versions of VDP, you were presented with the option to deploy VDP, which does not require a license key, or VDP Advanced, which requires a license key. A question commonly asked is “Do I have to deploy and license VDP Advanced at the replication target location even though I do not intend to perform backups there?” With VDP Advanced 5.5, you do have to deploy a VDP Advanced appliance to serve as a replication target, but VMware provides a “zero-CPU” license at no additional charge to enable an appliance to serve as a replication target for VDP Advanced. More details can be found in this blog article. While this was a pretty good workaround, the process for deploying an appliance as a replication target has been improved with the introduction of the VDP Replication Target identity in VDP 5.8. Naturally, you can find more information on the new VDP appliance identity in the VDP Administrator Guide, but Mohan Amarnath and Suraj Vithalkar from EMC have provided an excellent white paper that covers VDP Replication Target in detail including use cases and best practices. Click here to download the VDP Replication Target white paper.
I am sure most of you have heard about the “Shellshock” vulnerability – if not, you can read about it here. Seeing that the vSphere Replication 5.8 virtual appliance is running Linux, a patch is required. This short blog article shows how to fix this issue in vSphere Replication 5.8. To review more details on this security advisory, please see this page.
With the release of vSphere Replication 5.8, it is now possible to replicate virtual machines from a vCenter Server environment to another vCenter Server environment and to vCloud Air Disaster Recovery. Please understand that does not mean you can replicate the same VM to both, but rather you can configure replication for a VM to one destination or the other using the same vSphere Replication 5.8 user interface. Before vSphere Replication 5.8, you could deploy version 5.5 for replication between vCenter Server environments or deploy version 5.6 for replication to vCloud Air Disaster Recovery, but not both.
I have recorded a few short videos – less than two minutes each – to demonstrate using vSphere Replication to replicate virtual machines to both a vCenter Server environment and to vCloud Air Disaster Recovery. These videos do not have audio, but it is easy to understand what is happening in each video thanks to the simple interface vSphere Replication provides us.
I recently received an inquiry about whether vSphere Data Protection (VDP) Advanced could send backup data to an EMC Data Domain appliance with encryption enabled. This scenario was easy to set up and test. In my lab, I am using a Data Domain appliance running Data Domain Operating System (DDOS) 5.4 along with VDP Advanced 5.8. First, I verified everything was working properly (before encryption) by running a few backups jobs and performing both image level (VM) restores and application level (database) restores. Then, I enabled encryption on the Data Domain appliance when I was sure there were no VDP backup jobs, integrity checks, etc. running. After encryption was enabled, I again ran backup jobs and performed image and application level restores from restore points created both before and after encryption was enabled. All of these worked fine, as expected.
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:
- 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!).
- 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!
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…
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
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.
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.
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.