Kemp’s free loadbalancer

A few weeks back I reviewed Kemp’s LB for log Insight Manager. Today they have announced the availability of a free version of the LB they make. This covers a variety of different platforms. Of course if you are a large shop then the free version wouldn’t cut it for you but its definitely a good way to test the product out and be aware of its ability by running it in a lab. The differences in the free and paid versions are called out here. Enjoy!

Kemp LB for Log Insight Mgr

Just recently I was playing around with log insight or as they now like to call it vRealize Log Insight. One of the new features with 2.5 is the ability to have to have an integrated load balancer. In previous versions VMware allowed for log insight worker nodes to scale out but this introduced an issue with evenly distributing the load. With 2.5, the claim is an external load balancer is no longer needed.

KEMP has been in the industry for some time and offers load balancer for all kinds of solutions. In fact it was one of the first vendors to ever make a virtual load balancers for VMware ESXi back when it was just ESX as well as other hypervisors. Some of their VMware specific load balancers can be found here. The one we are interested in is called the LoadMaster for VMware vCenter Log Insight Manager. I know this can be a mouthful. But its functionality is pretty straightforward with simple deployment and maintenance.

I don’t want to go into the details of how to deploy KEMP’s LB. We will be referring to it as the VLM (Virtual LoadMaster). It is an OVF that can be downloaded from the KEMP Website. Once the OVF is deployed it takes minutes for this bad boy to start working. Their deployment guide can be found here which covers their entire process of deployment . Hence, there is no point in me repeating the same information. However, I will point out a couple of things which might make your deployment a bit easier specially if load balancing is not something you don’t work with on the regular basis or if you are new to log insight:

  1. You will need at least 2 Log Insight nodes deployed (you can work with 1 but then what’s the value of a LB?)
  2. Do not enable the ILB (internal load balancer if you are using log insight 2.5)
  3. Do not forget to install the Log Insight Add On pack once you have deployed the VLM (section 2)

NOTE: The LoadMaster build that will be posted to in early February will include the Add On Pack by default.

  1. A virtual address is the IP of the service often referred to as a VIP. Basically this will be the address your clients will connect to.
  2. The real servers in this case will be your Log Insight nodes. Once the client connects to the virtual IP, the VLM will forward them to one of the real servers (Log Insight nodes) based on configured scheduling methods and health checks.

The image below that I borrowed from KEMP does a pretty good job in giving you an over of what the VLM does.


I don’t generally deal with load balancers in general so I felt it was important for me to clarify some of the above information. The good news is that I was able to deploy and make this work within minuets and if I can, anyone can. I deployed 2 Log Insight nodes and configured my virtual services in VLM as well as added the two nodes as the real servers.. After pointing my ESXi servers to the virtual IP addresses, VLM was put to work.  Read the rest of this entry »

Boomerang to beam your VMs

Recently I got an opportunity to take BoomerangTM for a spin. I wasn’t familiar with the product prior to this opportunity. Boomerang allows you to move your VMware vSphere workloads to Amazon AWS. It allows you to do the following:

  1. Move your load to AWS
  2. Use AWS as a DR or backup
  3. Bring your load back from AWS to your vSphere environment

Boomerang has a very simple deployment, perhaps which would explain the absence of countless PDFs on their website. The steps to get going are simple. You will need the following:

  1. A vSphere environment
  2. An AWS account
  3. Connectivity between 1 and 2

To get started, you will download an appliance which is right under 600MB. Once deployed, the appliance can be powered on. It will acquire an IP address if DHCP is enabled and publish that in the summary page of the appliance in the vSphere client. But if DHCP is not enabled, accessing the appliance becomes a little interesting. I found some details here. Luckily for me I have DHCP available and was simply able to hit the appliance acquired IP once it was up. The default username and password are both ‘admin’ and it would obviously make sense for you to change them to something else. When you provide the appliance with the default credentials, you will be asked to provide the license key and the email associated with it. This will also be a good opportunity for you to change your default password. With a few other choices to make you will be ready to rock and roll within seconds.

In the Boomerang world you have the option to create protection groups that serve as containers. These containers are made up of VMs. In order to create a protection group, you will need to provide the following:

  1. vSphere admin credentials
  2. vSphere IP/DNS
  3. AWS access key
  4. AWS secret key
  5. S3 Bucket name

Once you provide this information, you will be able to create a protection group. In my case I used a PHDVBA appliance I had laying around. My only reason for picking this versus others was its smaller disk footprint. It would have been relatively faster for me to move this to and from AWS considering my Internet connection is not the fastest. Read the rest of this entry »

Participate in Project VRC “State of the VDI and SBC union 2015″ survey

The independent R&D project ‘Virtual Reality Check’ (VRC)  was started in early 2009 by Ruben Spruijt (@rspruijt) and Jeroen van de Kamp (@thejeroen) and focuses on research in the desktop and application virtualization market. Several white papers with Login VSI test results were published about the performance and best practices of different hypervisors, Microsoft Office versions, application virtualization solutions, Windows Operating Systems in server hosted desktop solutions and the impact of antivirus.

In 2013 and early 2014, Project VRC released the annual ‘State of the VDI and SBC union’ community survey (download for free). Over 1300 people participated. The results of this independent and truly unique survey have provided many new insights into the usage of desktop virtualization around the world.

This year Project VRC would like to repeat this survey to see how our industry has changed and to take a look at the future of Virtual Desktop Infrastructures and Server Based Computing in 2015. To do this they need your help again. Everyone who is involved in building or maintaining VDI or SBC environments is invited to participate in this survey. Also if you participated in the previous two editions.

The questions of this survey are both functional and technical and range from “What are the most important design goals set for this environment”, to “Which storage is used”, to “How are the VM’s configured”. The 2015 VRC survey will only take 10 minutes of your time.

The success of the survey will be determined by the amount of the responses, but also by the quality of these responses. This led Project VRC to the conclusion that they should stay away from giving away iPads or other price draws for survey participants. Instead, they opted for the following strategy: only survey participants will receive the exclusive overview report with all results immediately after the survey closes.

The survey will be closed February 15th this year. I really hope you want to participate and enjoy the official Project VRC “State of the VDI and SBC union 2015” survey!

Visit to fill out the Project Virtual Reality Check “State of the VDI and SBC Union 2014″ survey.

Good Ole P2V

This year I havent had much opportunity to blog due to the type of work I have been involved in. However, as soon as I find the opportunity I grab it and this one happens to be about P2V. I recently had to use P2V after a long time for a POC I cant share details about at this time. Having not done a P2V in ages, it will be safe to say that my confidence was sort of crushed from some of my initial tests. Here are some of the things I learned.

If your source machine, your P2V server (where convertor is installed), your vCenter and your target hosts have any firewalls between them, please go to this this link and make sure all the communication channels are open.

In my tests there were firewalls in play and we opened the ports accordingly. Once the ports were open we did a P2V and everything seems to have worked after some issues we faced with SSL. Once the SSL was taken out of the equation everything seems to have worked just fine.  The machine was imported to the target vCenter and powered on with no issues. Seemed pretty standard. However our later tests kept failing which was quite frustrating. The job would fail after a few seconds of being submitted with the following error:

“An error occured while opening a virtual disk. Verify that the Converter server and the running source machines have a network access to the source and destination ESX/ESXi hosts.”

BTW the error above is my least favorite as it could really mean so many things. The key is always in the log files. After looking through the log files of our repeated failed attempts, we noticed something interesting in the worker log file:

2014-10-29T11:18:21.192-04:00 [03652 info ‘task-2′] Reusing existing VIM connection to
2014-10-29T11:18:21.207-04:00 [03652 info ‘task-2′] GetManagedDiskName: Get virtual disk filebacking [Cluster-1] PhysicalServer/PhysicalServer.vmdk
2014-10-29T11:18:21.207-04:00 [03652 info ‘task-2′] GetManagedDiskName: updating nfc port as 902
2014-10-29T11:18:21.207-04:00 [03652 info ‘task-2′] GetManagedDiskName: get protocol as vpxa-nfc
2014-10-29T11:18:21.207-04:00 [03652 info ‘task-2′] GetManagedDiskName: Get disklib file name as vpxa-nfc://[Cluster-1] PhysicalServer/PhysicalServer.vmdk@ESXi4:902!52 c3 66 97 b0 92 a0 93-38 cd b9 4a 17 f8 e0 00
2014-10-29T11:18:33.048-04:00 [03652 info ‘task-2′] Worker CloneTask updates, state: 4, percentage: 0, xfer rate (Bps): <unknown>
2014-10-29T11:18:33.048-04:00 [03652 info ‘task-2′] TargetVmManagerImpl::DeleteVM
2014-10-29T11:18:33.048-04:00 [03652 info ‘task-2′] Reusing existing VIM connection to
2014-10-29T11:18:33.064-04:00 [03652 info ‘task-2′] Destroying vim.VirtualMachine:vm-810174 on
2014-10-29T11:18:34.062-04:00 [03652 info ‘task-2′] WorkerConvertTask: Generating Agent Task bundle for task with id=”task-1″.
2014-10-29T11:18:44.467-04:00 [03652 info ‘task-2′] WorkerConvertTask: Retrieving agent task log bundle to “C:\Windows\TEMP\vmware-temp\vmware-SYSTEM\”.
2014-10-29T11:18:44.483-04:00 [03652 info ‘task-2′] WorkerConvertTask: Bundle successfully retrieved to “C:\Windows\TEMP\vmware-temp\vmware-SYSTEM\”.
2014-10-29T11:18:44.483-04:00 [03652 error ‘Default’] Task failed:

One thing that stood out was the hostname that I have marked above in red. We were exporting the physical machine to a host in Cluster-1. When going through the wizard it allows you to select an individual host inside a cluster however that doesn’t really mean much. Our cluster was an 8 node cluster and we noticed in every failed attempt the job was trying to pick any of the 8 hosts in the cluster and not the one we selected (ESXi8). Also, right before submitting the job we noticed that though a particular host was selected as the target, at the summary page the target location was the cluster and not the individual host.

So remember I mentioned we have firewalls between our hosts, vcenter, source machine and P2V server? When we opened the ports we figured that we will only need access to a single ESXi host as the P2V wizard was allowing us to select an individual host in the cluster. As it turns out because this host was in a cluster all hosts in that cluster will need the communication channel open as it was evident through the worker log file. Once we made that change, the P2V worked like a champ over and over. Another option would have been to take our target host out of the cluster.

So, how did we get it to work the first time? I blame that on luck. We went back to the log files and confirmed the first time it actually worked, it happened to have selected the host we opened the ports for. I should have bought the lottery ticket instead :(.  Luckily we tested more than once and were able to confirm all that needs to be in place for this to work. I may have known this sometime ago but being away from P2V for sometime it was refreshing, challenging and rewarding to finally get it working. Convertor version was 5.5.1 build-1682692.

Lesson learned? Do lots of testing.

PHD Virtual Backup (v 8)

Recently I got an opportunity to play around with Unitrends backup solution, which is still in beta. For those of who are not aware, PHD Virtual is now part of Unitrends. At first I was a bit skeptical because I have seen products being wasted after an acquisition. But in this case I think I am quite happy with the progress the product has made under the new name.

My goal is to share my views on my testing of the product and also try and explain the new architecture. Once you get a hang of it, its really simple and makes a lot of sense. In my initial attempt, I sort of screwed things up but that was mostly because I was being hasty and didn’t bother reading the few simple concepts.

Like in previous version, the one we will discuss here, version 8 revolves around the good ole VBA. However now the VBA does a lot more and has delivered on the promises in the past. For example: my previous complain was lack of single pane of glass to manage multiple VBAs, that’s no longer a problem here. In fact they went a step further and made it possible to manage VBAs that could be deployed in Citrix or even Hyper V environments.


In version 7, the concept of appliance roles was introduced and version 8 continues with this model. Each appliance can be dedicated to a single role or a single appliance can have multiple roles configured. So what are those roles?

Presentation (P) – The Presentation appliance is the appliance running the web-based interface you use to configure and manage your installation. Only one presentation appliance is necessary per installation, across all configured environments (including across all hypervisor types). All management and configuration of PHD Virtual Backup occurs through the Presentation Appliance’s web interface.
Management (M) – Each Environment requires one appliance designated as the Management Appliance. This appliance performs inventory and other hypervisor-specific tasks and manages the work of the Engine appliances. Each environment you add to your PHDVB deployment requires the IP address of one appliance to act as Management appliance. The Presentation Appliance can also be designated as a Management Appliance.


Engine (E) – Engine appliances perform the actual data processing and send data to their configured data stores. Engine is the most common role an appliance will take on in your deployment. Appliances with the Presentation and Management role can also be configured with the Engine appliance.


Note: As a general recommendation, you will need at least one Engine appliance for every 10 TB of source data you will protect (or every 1 TB of data if using XenServer or 5 TB is using CIFS backup storage).


So for any deployment you will need at least one VBA that has the P M and E roles. If the environment is small enough, a single VBA can host all those roles. And then add more engines as the environment grows. You can tell someone was thinking scaling. The latest version of the beta also incorporates a tutorial video that gives you a high level view of what the VBA roles may look like when laid down. This will also assist you in determining what will be ideal for your environment. I highly recommend you watch this before moving forward with the full configuration.


I am stealing a diagram from Unitrends documentation to explain how the roles can be laid out.

Deployment single hypervisor

Read the rest of this entry »