Virtualisation

Archived posts from this Category

VMWare & Virtual Machine Replication

Posted by admin on 24 May 2009 | Tagged as: Databases, IT Stuff, VMWare, Virtualisation

This is a brief look at the use of vReplicator from Vizioncore for replicating VMWare VMs to a disaster recovery site. The information is based on my experiences in setting up this environment for my employers.

Main site is a VMWare ESX 3.5 HA cluster (Intel CPUs) and SAN with multiple VMFS filesystems. Remote site (300K from main office) is a single VMWare server (AMD CPUs) with 2 VMFS filesystems on RAIDed internal storage. The 2 sites are connected by 10Mbps optical fibre. Both sites are managed through Virtual Center which is installed into a VM in our main site. To backup our main site VMs (including Virtual Center) we decided to use vReplicator from Vizioncore.

Installation was very easy, just run the installer and follow the prompts to set it up - we installed vReplicator into the same VM as our Virtual Center installation. vReplicator logged in to our VC and discovered our HA cluster, the VMs it contained and also our remote server and its VMs.

Using it was just as easy, you select the VM you want to replicate, click the “Create Job” link and complete the details. There are dropdowns for resources like VMFS filesystems on the target and you can select which of the VM’s disks replicate to which remote VMFS filesystem.

Which type of replication? We used what vReplicator refers to as “Differential” replication which is essentially a point-in-time comparison of original and replicated VMs and uses a VM snapshot to capture changed data. The other type of replication supported by vReplicator is called “Hybrid”. Hybrid replication uses a “change over time” model to identify what should be replicated. It is faster because there is no need to scan during the replication pass but uses more disk space for its (2) snapshots. It was largely because of constraints on the amount of disk space available for snapshots that we selected “Differential” replication.

Once you save a job you can leave it to autostart at the time/date you designated or you can run the job now by clicking the “Run” menu item for the job. The first replication takes quite some time as the entire VM has to be copied. Subsequent runs are much quicker. In our case a replicate job for a fairly static VM which took 3 hours for the first run takes around 30mins for 2nd and subsequent runs; another job for our main SQLServer2005 VM which took 11 hours for the first run takes about 2-3 hours for 2nd and subsequent runs.

At the moment we are replicating 4 VMs, all Windows 2003, including our Virtual Center VM and 2 SQLServer database installations (different vesions). Shortly we will be adding Centos 5.x Linux VMs with our mailserver and Samba installations.

So vReplicator in a nutshell, easy to install, easy to setup and configure and easy to run. Things to watch out for are that you have enough space for the snapshots that vReplicator uses and that you have enough bandwidth to move the amount of data you want to move in the time window you have available.

Separately to the VM replication outlined above we have an additional Linux VM in our remote site which has a redundant DNS server, a synchronised OpenLDAP replication configuration and a redundant RADIUS server. These servers provide secondary DNS, radius and authentication services for both our main site, our remote site and regional offices.

Cloning VMWare ESX VM By Hand

Posted by admin on 22 Oct 2008 | Tagged as: IT Stuff, VMWare, Virtualisation

I know, you’re asking why would anyone want to do this? Well the answer is that the version I have to work with (VMWare ESX 3.0.2 Starter Edition) does not include support for cloning VMs!!!

Firstly you need to read the excellent notes posted by Mario at http://www.mariospina.com/braindump/ on cloning VMWare ESX 3.0.1 by hand. In addition to the steps that Mario lists in his notes, I found that:

  1. I could not rename the *flat.vmdk as there was some binary reference to it.
  2. You must recreate the ethernet connection otherwise you will have multiple VMs with duplicate mac addresses (obviously you also need to change the ip address of the VM as well).
  3. I had to change the vm machine id VMId in the .vmxf file so that it was unique amongst all the VMs. I guess this could eventually come back to bite me if/when VMWare creates a VM with the same VMId!!

I should also add that these instructions seem to work OK on VMWare ESX 3.0.2.