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.

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.

Architecture:

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.

Deploying:

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 »

New Toy from PHD – RTA Caluclator

PHD Virtual recently released a free tool called the Recovery Time Calculator that enables the calculation of time it will take to recover virtual machines and critical applications in the event of an outage or disaster. Did I mention its FREE? Below is the press release.

Dubbed the RTA Calculator, for the ‘Recovery Time Actual’ estimate it provides, PHD’s free tool can be easily downloaded and then immediately provides visibility into what your organization’s actual VM recovery time would be in the event of an outage.

The RTA Calculator has a built-in wizard to connect to VMware. Once installed you are prompted to select the VMs you wish to time for an RTA estimate, and set the appropriate boot order. The RTA Calculator will then take a snapshot and create linked clones for each VM. Due to the use of snapshotting and linked clones, the VM creation process is very quick. The tool then simply powers up the VMs and times the process, calculating the total time it will take to recover that grouping of VMs – it’s that simple! This gives you an accurate Recovery Time Actual you can use to compare to your Recovery Time Objective and determine if you’ll be able to adhere to your SLAs.

Run the RTA tool as often as needed to produce an estimate with different production loads.

What You’ll Need

System Requirements

Like all PHD Virtual products, the RTA Calculator is highly effective while still maintaining ease of use. It requires no training or product documentation. All you need to know is contained within in this short video demonstration

Other than that just ensure you meet the following 3 requirements

  • The RTA Calculator is a Windows application that requires an Administrator account and .Net 4.0.
  • The RTA Calculator supports VMware ESX or ESXi with vCenter 4.0 (or higher) with default ports.
  • The RTA Calculator will need the VMware guest tools installed.

Download the FREE tool here: http://www.phdvirtual.com/free/rta-calculator

CloudPhysics and Admission Control tunning

A while back I made a little demo video that showcased one of CloudPhysics cards that is still my personal favorite. I figured it would be a good idea to share it in case there is anyone out there who hasn’t taken CloudPhysics for a spin yet.