Vizioncore vReplicator 2.1

This is a product that can be deployed by any company irrespective of its size and with almost no real computing knowledge.

IT Pro Verdict

This is a product that can be deployed by any company irrespective of its size and with almost no real computing knowledge. The price per replicated VM may put off some smaller companies that have just one or two servers but typically 8-10 VMs, though enterprise licensing is available.

Virtualisation has been around for a long time but only in the last five years has it ventured out onto commodity servers with VMware leading the market. The reason that virtualisation has been so quickly adopted is cost. The average single application server uses less than 20 per cent of its resources for 95 per cent of the time. With an increasing number of applications becoming business critical, IT departments are often dedicating two servers to ensure that should one fail, the application and the business keeps running.

Making better use of resources means running multiple applications on a server. The problem with this is interaction between the pieces of software. This is where virtualisation becomes attractive. It creates a completely separate environment for each piece of software running it in its own virtual machine. This means that if one application crashes, it doesn't affect the other virtual machines on the server.

A spin off is that rather than dedicate two server to an application, high availability can be achieved by having multiple copies of a virtual machine on different physical machines. Should one copy fail then you can switch users to the second copy. This is also part of any disaster recovery planning where copies can be maintained off-site.

Good ideas often have unexpected consequences. The unexpected consequence of virtualisation has been the explosion of virtual machines in the datacentre. Tracking and managing these machines has become a full time job. For disaster recovery planning, it is essential that replication is done on a reliable and consistent schedule.

While the various virtualisation vendors have their own tools for this, they do require you buy into their large scale enterprise solutions. For those who don't want to commit this way, there needs to be an alternative to managing virtual machines. Vizionsware's vReplicator is one such tool.

So what is in the box? In short, nothing! Like an increasing amount of software today, you download vReplicator from the Vizionware website and start with an evaluation key. When you want to purchase and deploy vReplicator you simply change the licence file.

The software is just a 5MB file from the website and comes as an MSI (Microsoft Installer) file.

Documentation is downloaded from the website. There was a quick setup and getting started guide but the user manual had been replaced with the beta manual for the next version. This was annoying but we expected the built in help file to resolve this.

This proved to be quick, simple but with an unexpected gotcha. To install vReplicator, you run the MSI file that you had previously downloaded. There is no need to install onto a server, you can put the software on any workstation that you want.

The minimum requirements are fairly low end although it does want 2GB of disk space. This is to accommodate the log files over time as the actual software itself takes just 25MB. Vizioncore claims that the software will run on Windows 2000 SP1 or greater. Not quite true. We could not get it to run on Windows Vista at all. On the upside, it will install into its own virtual machine irrespective of whether you use Microsoft or VMware.

There are a small number of other requirements. In order to talk to the VMs vReplicator uses SSH which means that port 22 must be open on the host and the VM you want to talk to. If you are working with VirtualCenter, there are other ports that will need to be configured. This takes just a few moments to configure.

Vizioncore has decided that it will only support the Virtual Machine File System (VMFS) that ships with VMware's ESX 3. If you have older machines you will need to update the underlying file system. If you are a relative newcomer to VMware, this should not be a problem but if you have a lot of VMs, you may have to do an unwanted upgrade in order to implement vReplicator.

Once the install is finished, which takes less than five minutes, you then start the process of configuring the software. As everything is wizard driven, you should consider ignoring the configuration options during the installation and do it as a separate process. You will need a good understanding of your infrastructure, where your VMs are located and where the replicated VMs are to be located.

The GUI is very simple and easy to work with. At a glance you can see all the information you need and the current status of ongoing jobs.

The first thing you need to tell vReplicator is the email address(es) to which alerts are to be sent. As there is no integration with any email system, all addresses need to be input manually. Should an address change later, you will need to remember to come here and make changes.

You will also need to know the details of the SMTP server through which alerts will be sent. Unfortunately, Vizioncore has omitted to provide an option for companies who only allow authenticated clients to send through their servers so you need to create an exception in your email system.

You don't add virtual machines into vReplicator, instead you add VirtualCenters or host machines. Later, when you come to create jobs, you open either of these two containers and they will display the list of VMs that you can work with. In both cases you will need username and password data in order to create an access.

That is effectively all there is to installation and basic configuration. The next stage is to create the replication jobs that will be used to manage the VMs.

The vReplicator model is a simple, three phase model - initial setup of the replication, determining the interval of replication and the success/failure log.

Before creating any replication it's important to think through where the two VMs are located, how they will communicate, the amount of data (changes) that will be replicated and how often you will need (want) to carry out replication.

Initial replication can take some time depending on the size of the VM and the speed of the network between the two VMs. For example, if you are looking to replicate a VM that is located in a branch office running over an ADSL link, you will want to ensure you have a weekend to do the initial phase. Conversely, if you are simply replicating to another server in the datacentre, you will be working at the speed of your internal network.

Replication is created through the Job wizard. You can create a series of jobs and then apply them to several VMs or you can create a unique job for each VM.

To create a job you expand the VirtualCenter or Host to see a list of available VMs and then select your VM. Once done, either Add a New Job or Assign an existing job. If this is a new job then the first thing you need to is assign a name to the job and a description. You should also select who is to be notified when each replication completes. You can put any valid email address in here provided you entered it earlier.

Next you set the replication frequency for the job. To prevent a problem with a replication starting before the previous one has finished, the replication interval is the length of time from the completion of the previous job to the start of the next job. Even if you set an interval of 15 minutes (the minimum allowable interval), should it take 1 hour to replicate, there will be 1hr and 15 minutes of data to replicate next time. It is recommended that for critical servers you carefully monitor how long replication takes. Once you have defined the interval, you just need to set the initial start date and time.

The next step is to choose the host to which you want to replicate this VM. You need to be able to see the host server so if it is located on a different site, ensure that you can browse to it. Vizioncore recommend that you check the box that disables Guest Quiescing if you are replicating a database product to prevent locks on data rows during the replication process.

The first time a replication takes place, vReplicator takes a snapshot of the VM, copies the data to the target creating the new VM, builds a Virtual Machine Disk Format (VMDK) map, commit the snapshot of the VM and complete the data transfer.

From that point on, every replication consists of comparing the two VMDK maps (source and target) and then moving just those blocks that have changed. The target VMDK map is then recreated and the replication complete.

This was an incredibly easy product to setup and configure. The only two points of annoyance were that the help file points to a location on the Vizionware site that is no longer there and the lack of authentication when talking to an SMTP server.

As there is no way of updating the help file until the next version ships, this seems sloppy of Vizioncore. The only other alternative is to download the beta documentation for the next version.

This process can easily cope with moving multiple VMs over an ADSL link allowing for replication from branch offices to datacentres or even from the office of a small business to the home of a director.

This is a product that can be deployed by any company irrespective of its size and with almost no real computing knowledge. For dealers that are increasingly looking to offer services to the SME market, there is clearly scope here for some value added services. ISPs might also want to consider this as an extension to the existing "network" storage offers they already have in place.


This is a product that can be deployed by any company irrespective of its size and with almost no real computing knowledge. The price per replicated VM may put off some smaller companies that have just one or two servers but typically 8-10 VMs, though enterprise licensing is available.

vReplicator requires a physical or virtual machine running Windows 2000 SP1 or greater and the .NET Framework version 2.0. Pentium III class CPU or greater 256MB RAM (512MB preferred) 2GB free hard disk space (4GB or greater preferred) 1024x768 video resolution (1280x1024 or greater preferred) 100 Mbit/sec or greater network adapter Unimpeded network SSH access (port 22) from vReplicator to both source and destination servers