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.
Category Archives: Uptime
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.
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.