Unitrends Free – Review of the free edition

I have reviewed the Unitrends backup solution in the past. I have had some very good experience with it. The solution was licensed on a per socket basis and worked on both ESXi and Hyper-V. Unitrends have now announced the “Unitrend FreeTM” Edition, which is FREE.

FREE vSphere and Hyper-V VM Backup – Unlimited VMs and Sockets – Hypervisor level protection for vSphere and Hyper-V for up to 1TB of production VM data – there’s no tie to the number of VMs or sockets in the environment.”

Installation:

The installation process is pretty straightforward. But you will need at least one windows machine to launch the installation from. Basically, the windows installer (exe) needs to be executed from a machine running .Net framework 4.0. That will fire up the installation wizard that requires some very basic information (IP address of the new backup appliance etc). I have only tested this for the ESXi version. In the ESXi version, I provided by vCenter address and credentials and it was pretty much next next next from that point on.

What happens in the background is an appliance is deployed with the information you have provided. Once the wizard is complete, the appliance is up and ready to be accessed via the web using the IP address you have provided.

In case you are skeptical about this approach versus just having access to an OVA/OVF that you can deploy yourself. Imagine this, you work in an environment that has a separate backup team, as a virtualization engineer you will only have to provide them with an account that has permissions to deploy the appliance and turn it on without giving them access to anything else. They can simply use the installation wizard without ever hitting the vSphere client. For that use case that approach makes a lot of sense. Read the rest of this entry »

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 KEMPtechnologies.com 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.

KempVLM

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 www.projectvrc.com/blog/23-project-vrc-state-of-the-vdi-and-sbc-union-2015-survey 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 10.194.0.120
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 10.194.0.120
2014-10-29T11:18:33.064-04:00 [03652 info ‘task-2′] Destroying vim.VirtualMachine:vm-810174 on 10.194.0.120
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\agentTask-task-1-vmepkywh.zip”.
2014-10-29T11:18:44.483-04:00 [03652 info ‘task-2′] WorkerConvertTask: Bundle successfully retrieved to “C:\Windows\TEMP\vmware-temp\vmware-SYSTEM\agentTask-task-1-vmepkywh.zip”.
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.