Concept Explained: Running Multiple vSphere Replication Appliances

Playing with vSphere Replication in my lab recently (following my joyous experiences with my HP MSA P2000 detailed here), I came across a small gotcha that might catch out some of those who (like me) learn stuff by playing with them, whilst reading about the deployment technical aspects alongside.

vSphere Replication in vSphere 5.5 has been enhanced over the v5.0/1 release, to enable multiple replication appliances to be deployed and managed by the same vCenter instance. vSphere 5.5 allows upto 10 replication appliances per vCenter, selectable on configuring a VM for replication or available for auto-selection.

The gotcha comes when registering subsequent appliances to a vCenter after initial replication connection has been established between a remote and a local vCenter.


When configuring vSphere Replication, a single appliance (listed as ‘Embedded’ in the Web Client) is listed in the vCenter Inventory > vSphere Replication > (vCenter) > Manage > vSphere Replication > Rerplication Servers. Additional servers can be deployed (up to a maximum of 10) using the following model:


Note: There is a single ‘embedded’ or a master appliance, which maintains the VRMS and an embedded database for the vCenter. This tracks replication for all the VMs for the vCenter instance. Additional appliances registered to the vCenter do not maintain their own databases – instead they are slave or secondary to the embedded or master appliance. (The dependency arrows might not be 100% correct in terms of direct communication, but this is just to demonstrate the principle that secondary appliances don’t maintain their own databases, instead using the embedded DB in the primary or master appliance).


When deploying a second, third, or fifth appliance to a vCenter, remember:

  • DON’T deploy a second vSphere Replication appliance from the original OVA file downloaded from VMware.
  • DO use the Replication Servers screen in Web Client to register additional appliances to the existing vCenter server.
  • DO use the ‘Add On’ package downloaded alongside the original OVA file from VMware for deployment of additional appliances, not the original OVA file itself.

IF you do deploy a second complete OVA master, and register it with the vCenter Server, this will corrupt the entry in the vCenter Inventory for vSphere Replication, and the connection will need to be removed and reset for the two appliances to connect and communicate for the purposes of replication.

Improving vSphere Web Client Performance

With the release of the (now maturing) VMware vSphere 5.5 release, more and more operations (but not all – yet) are being migrated to the vSphere Web Client.

Functionality of the vSphere 5.1 features are all fully available in the vSphere 5.5 .Net Windows client (the traditional client) along with Site Recovery Manager and Update Manager administration functions, but any and new vSphere 5.5 features are now only available via the web client.

Lots is made of the performance of the web client, and having used it on my home lab and now in Production environments, I can see why some users report on there being some perceived performance lag in the web client compared to the Windows client (population of menus, general navigation etc).  First off, a direct comparison of similar tasks shows the Web Client is slower compared to the Windows client, but there is a couple of things you can do as an administrator to improve the situation.

  1. Use a local browser on a server via a jumpstation if connecting to the infrastructure remotely. It might sound obvious, but with the Web Client using Flash – if you are connecting over a home broadband, VPN or WAN link to your DC, then decreasing the traffic route between the browser and the vCenter server improves performance significantly.
  2. Change the Flash settings of your browser. Because of the Web Client’s reliance on Flash, there are some settings that can assist in improving the performance of the Flash plug-in within the browser. Changing the ‘Local Website Storage’ setting can increase the temporary storage available to Flash from a default 100kb setting to something higher and more performant. This setting is set low intentionally because of security in Flash, rather than specifically for the vSphere Web Client. Fortunately, Adobe give a simple live view of the flash settings for your browser – to enable simple updating of the required setting.
    1. Visit:
    2. In the live view box, select your vCenter server (either by DNS or IP address) – see image below.
    3. Change the settings slider from 100kb up to 10MB or unlimited (mine is set to Unlimited).
    4. Close the website and browser session.
    5. Reload the Web Client. Is performance better? It might be with usage…..
  3. Another tip is to change the Tomcat configuration on the vCenter server. VMware has a KB published on this, where they talk about the ‘Small’, ‘Medium’, and ‘Large’ infrastructure instances we see at installation time. This change is about changing the JVM heap size to 3GB (usually for large installations), as this then impacts the vFabric tc Server on which the vCenter server is based. I have used this a couple of times for customers who have seen performance degradation on their vCenter Web Clients.


Hopefully these tips are useful – and the performance of your vSphere Web Clients improves as a result!

Update: Apparently VMware Support may use blogging sites to forward information to customers! Item 2 in the list above is also listed on the virtuallyGhetto blog of William Lam (Twitter: @lamw).

vCenter’s Number – Is It Up?

(This is all based on information that’s in the public domain at the time of writing and is all my own opinion. I may very well be wrong!)

ESXi first saw the light of day as version 3.5 in 2007 / 2008. Rumours were rife after ESXi 4.0 was released in 2009 that the clock was now ticking on ESX “Classic”. With the release of 4.1 in 2010 VMware finally confirmed the rumours and, from 5.0 onwards it’s been ESXi only.

You know this already of course if you’ve been working with vSphere for any length of time. The reason that I’m bringing it up though is because I think it’s a clue as to what’s going to happen to vCenter in the future.

The vCenter Server Appliance (vCSA) first appeared as a technology preview called “vCenter 2.5 on Linux”. It became vCSA as of vSphere 5. Subsequent releases (5.1 and 5.5) have seen many changes and it’s becoming more compelling with each version. Could it be only a matter of time before VMware announce that vCSA will be the only version of vCenter available? I believe it is VMware’s intention, yes.

Consider VMware’s recently published convergence plan for vCD. It states that the functionality offered in vCD will gradually be separated and merged into either vSphere / vCenter or into vCAC. The timetable for this change isn’t clear yet but given that vCD is Linux based, it might be more logical (or simpler) to integrate some of its functions into vCSA rather than into vCenter for Windows.

Look at many of VMware’s other products and a good number are linux appliance based. Of course there are exceptions, with perhaps some of the biggest currently being vCAC and Horizon View, but they’re both acquired products.

Increasingly we’re also seeing a move away from a Windows vSphere Client to a Web Client. Some functionality in vCenter 5.5 is only accessible via the Web Client. Of course the Windows Client might be kept on as a means to administer the free version of ESXi – time will tell.

None of these things are concrete proof of intent but they, and other things, make my spider senses tingle. It might not happen with as there could be some challenges to overcome still. There would have to be complete support and integration with VMware’s other products as one example. As another example, some customers might want vCSA to support MSSQL before they’d consider it ready for production.

In short though, I think that vCenter’s days on Windows are numbered. What that number is though, I couldn’t say.

Force Removal of Licensed vCenter Products

Once in a while, you need to remove or update licensing in vCenter to account for products that have been registered or interact with vCenter Server.

Unfortunately in some cases you need to force unregister products for vCenter Server – say if a product was registered and then deleted without being unregistered, or if an evaluation period has expired but the Evaluation version is still present in vCenter.

The solution is simple if not at first immediately obvious. Follow this process to force unregister a prodult from vCenter:

  1. Login to vSphere Client.
  2. Home > Licensing.
  3. Switch to View by: ‘Asset’.
  4. Right-click the asset or evaluation you want to remove.
  5. Select the bottom option: ‘Remove Asset’.
  6. Accept the warning message.
  7. Check that the asset has been removed from the licensing inventory.

Note: This process should only be followed if there is no chance the product cannot be unregistered automatically, i.e if the registered vApp has already been deleted. If at all possible, best practice would always be to unregister the licensed asset before deleting it.

Manual vCNS / vShield Edge HA Little Gem!

vCNS-HARecently, I have been doing lots with vCNS and manual creation / manipulation of vShield Edge devices (posts coming soon). One thing that drive me crazy is a tiny little thing that prompted me to write this quick Little Gem – ‘Edge HA’ sat on my to do list, and gloated at me…..

When creating a manual vShield Edge device in vCNS, there is the usual opportunity to create an pair of appliances for running the pair in High Availability mode. Trouble is, the options for deployment are limited and not very clear. (This might be clear / obvious to some, but weren’t to me!)

When creating an HA pair, in the vShield Manager console editing the Edge device in question under Settings – the HA Configuration gives few options. Essentially, ‘Enabled’ or ‘Disabled’, vNIC, Declared Dead Time and Management IPs. Here’s where my confusion was based. Management IPs. So many questions……!

The option for Management IPs is even outlined. 2 IP entry boxes, and note text: ‘You can specify pair of IPs (in DIDR format with /30 subnet. Management IPs must not overlap with any vnic subnets’.

OK, so I need Management IPs to manually create a HA pair. What /30 address range do I need to specify? Can the IP range share an existing vNIC, or does the Edge device need another interface or uplink. Where do I define the /30 addresses. Do they need their own vLANs? Must I create a whole new private address range specifically for HA heartbeat? Like I said – so many questions. Scour the documentation, Google ‘vShield Edge Management IPs’ produces no helpful results. So – to the LAB!

Turns out, you don’t need Management IPs at all. Simply change the HA Status to ‘Enable’, select a vNIC to support HA heartbeat, and add a second Edge appliance via the green plus symbol (it will prompt for the parameters) to deploy the HA pair! When both report as ‘Deployed’, HA is configured and your Edge device is protected.

Sigh. Like I said. This might seem obvious to some, but it wasn’t to me. ‘Edge HA’ is no longer on my to-do list!