Monthly Archives: April 2015

Scheduling Veeam Backup Free Edition backups

veeamlogoAs you might be aware Veeam has released Update 2 for it’s Backup and Replication software.  With that comes a slew of updates, integration with Endpoint Backup, vSphere 6 support, features, enhancements, bug fixes – you know the usual suspects that you might find inside of an update pack – you can see them all in the release notes here.  Speaking of release notes – it’s always a good idea to read completely through them before even considering an upgrade – not just to find any known problems or gotchya’s, but at times, mostly all the time you will find a feature or change to the product that isn’t marketed and publisized as much as the rest.  Now Veeam B&R update 2 is largely about Endpoint Backup integration and support for vSphere 6.0 –which is awesome – but as I was doing my once over of the release notes I noticed this….


Veeam has a long history of releasing so-called Freemium products – giving a way a scaled back portion of their complete solution absolutely free, while offering a paid license for those looking for enterprise features.  Veeam Backup Free Edition is exactly this – allowing administrators to create full backups of their VMs using VeeamZip technologies – absolutely free.

The one caveat to this was you were never able to schedule your VeeamZips – so creating a backup was something that had to be manually triggered.  I’m sure many of you (as have I) have tried – only to see the infamous “License is not installed” message when running the Start-VBRZip PowerShell cmdlet.  Well, as of update 2 you can kiss that message goodbye and begin scheduling that cmdlet to your hearts delight.


This is a relatively easy process but in the interest of completeness let’s go over it anyways.  First up we need to create a PowerShell script that will execute the Start-VBRZip cmdlet, which inturn VeeamZips our VM.  The script I used is below…

#Load Veeam Toolkit
& "C:\Program Files\Veeam\Backup and Replication\Backup\Initialize-VeeamToolkit.ps1"
#Validate any parameters
$vmentity = Find-VBRViEntity -Name $VM 
if ($vmentity -eq $null)
  Write-Host "VM: $VM not found" -ForegroundColor "red"
if (-Not (Test-Path $Destination))
  Write-Host "Destination: $vmname not valid" -ForegroundColor "red"
if ($DisableQuiesce -eq $true)
    Start-VBRZip -Entity $vmentity -Folder $destination -Compression $Compression -AutoDelete $Autodelete -DisableQuiesce
    Start-VBRZip -Entity $vmentity -Folder $destination -Compression $Compression -AutoDelete $Autodelete

A couple things about the script – you can see that it takes 5 parameters; the VM to backup, the destination to back it up to, the level of compressions to apply, whether or not to queiesce the VM and the auto-delete policy to apply to the backup.  From there we simply load the Veeam toolkit, do a little error checking and then initiate the backup with Start-VBRZip.  Pretty simple stuff – you can go ahead and try it by saving the script and calling it like so…

VeeamZip.ps1 –VM “VM1” –Destination “E:\backups” –AutoDelete “Never” –Compression 5 –DisableQuiesce $false

Scheduling the script

scheduledtaskPick your poison when it comes to scheduling this script to run – I’ve chose the standard Windows Task Scheduler to do the job. So go ahead and create a scheduled task with whatever schedule you like within Windows –  The only really tricky part is passing the arguments to the script – the way I have done it is by selecting ‘Start a program’ as my action, passing the path to PowerShell.exe in my program script, then enclosing my string arguments in single quotes, and the complete arguments string in double quotes like below

Program/script: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

Add arguments: “c:\VeeamZip.ps1 –VM ‘VM1’ –Destination ‘E:\backups’ –AutoDelete ‘Never’ –Compression 5 –DisableQuiesce $false”

From there it’s a matter of creating as many scheduled tasks as you have VMs you want backed up, or modifying the script to backup all your VMs – Either way, as you can see, the Veeam Backup Free edition has received a nice little feature buried within the Update 2 release notes!!!!

VXLAN on Ravello between Google and Amazon EC2

v2Ravello_Logo_largeA week or so ago I did a post around a cross vCenter vMotion lab that I had setup utilizing both Amazon EC2 and Google Cloud through Ravello Systems new beta which allows us to run nested ESXi.  It was a fun project to work on, migrating VMs back and forth through the clouds, but I tried to keep a lot of the technical detail out of the post – focusing more on what Ravello had to offer.  One key aspect of the setup was creating a VXLAN tunnel in order to bridge the two VM networks inside of each cloud – allowing me to complete the vMotion without performing any additional network configuration on my VMs once they had migrated.  Anyways, I thought I’d go into a little more detail on how I accomplished this.

Now, keep in mind here I don’t claim to be any sort of network guy – it’s probably my biggest lack in terms of IT skill-sets, therefore I could be going about this all wrong – any advice, comments, just leave the in the box below – I always appreciate any feedback I get.  I also appreciate any help I get, and had a lot with this project – CTO of Ravello Systems Alex Fishman had a couple of calls with me offering up his experience (very very smart guy).  Also, there’s a blog post on Ravello’s blog which goes over the setup as well – that said, I thought go into a little more detail in the case that someone else at the same level of network knowledge as myself might be looking for help.

So to start let’s have a brief look at the Ravello setup.  Firstly we need a couple of applications, one published to the EC2 cloud and one published to the Google Cloud.  Each application (in this case) contains two VMs – one to act as a client and one to act as the gateway/vxlan bridge.  I’ve used Ubuntu 14.04 server for these but you could use any OS you like, so long as the vxlan module is loaded and supported.  The table below outlines each VM and the networking associated with it in my test setup.

Cloud VM Network IP Notes
Amazon EC2 ec2-vxlan eth0 IP:
GW: None
Network Gateway
eth1 IP:
External network w/ Elastic IP attached
ec2-client eth0 IP:
GW: (in OS) None in Ravello
Google google-vxlan eth0 IP:
GW: None
Internal Network Gateway
eth1 IP:
External Network w/ Elastic IP attached
google-client eth0 IP:
GW: (in OS) None in Ravello

I’ve used a /29 subnet on the external networks as I really only need 3 total IPs available, one for each of the vxlan VMs as well as a third for a gateway – Honestly again you could use whatever you wanted here.  I understand that sometimes a picture is worth a thousand words so here is a side by side of both the Amazon and Google network canvas.

ec2networking googlenet

So a pretty simply setup when looking at the canvas – essentially the vxlan VM will need two NICs, one connected to the internal lan (eth0 in this case) and one connected to an externally routed network (eth1).  Before we finish up within the Ravello canvas and establish a tunnel let’s first look at the EC2 side of things so we can better understand the settings on the vxlan and client VMs that end up making our network canvas look like the above.

ec2-nic1 ec2-nic2

Looking closer at the network configuration of the ec2-vxlan VM (sorry, couldn’t get it all on one screen cap so I put them side-by-side) we can notice a couple of things; eth0, the internal lan (which will act as a gateway for the client VMs) is setup on the network with no gateway.  Also, we have selected public IP for this nic under external access but left the ‘Even without external services’ unchecked.  What this does is ensure that this VM can only be accessed by routing through our vxlan tunnel and cannot be accessed directly from the internet.  The second nic (eth1) is the nic we will use to establish our vxlan bridge.  This nic is subnetted in a way that allows very few IPs within the network, as we only need three anyways (one for ec2, one for google, and one for a gateway).  This nic has an Elastic IP tied to it within the External Access settings.  Since we will need to use this public IP later when we establish the tunnel it’s best that it not change often, and an elastic IP will never change, thus why we used it.


Another note in regards to the vxlan VM is the external services provided.  For this case I’ve simply allowed all external traffic on all ports into eth1 – probably not the greatest feat in terms of security but it sure does ensure I get the communication I need. (might be able to change to just other IP).

Note that you will need to setup the Google side of things inside Ravello exactly the same as shown above, obviously replacing the IP addresses of eth1 with those shown in the table earlier.  Once done with that we have completed our setup within Ravello and it’s now time to setup the tunnel.

Again, let’s start with EC2 and work our way over to google.  Take note of both your EC2 and Google elastic IP’s as we will need them for the configuration below.

First is our network configuration (/etc./network/interfaces).  Below is a shot of mine – the key here is that even though we specified an IP in the Ravello interface for eth0 we are not doing it within Ubuntu – we will be using this IP on our bridge instead, however we still want eth0 to be active so we set it as manual.  So as far as network interfaces your setup should be similar to below – of course with address being on the Google cloud.

# The primary network interface
auto eth0
iface eth0 inet manual
auto eth1
iface eth1 inet static

Once we have our network interfaces set up we can continue with the setup of the vxlan and bridge.  First we will walk through the EC2 side and then move to google.

We begin by adding the vxlan device with “ip link add mtu <MTUSIZE> <VXLAN DEVICE NAME> type vxlan id <VXLAN ID>”.  For example on the EC2 side I ran..

ip link add mtu 65000 vxlan1 type vxlan id 1

Then let’s create a new forwarding database entry on our vxlan device to allow all traffic through using “bridge fdb append <MAC> dev <VXLAN DEVICE NAME> dst <DESTINATION ADDRESS>”.  For example, I used the following on my EC2 instance – ensuring I use the public IP of the Google Cloud.

bridge fdb append 00:00:00:00:00:00 dev vxlan1 dst

From here we can add our bridge using “brctl addbr <BRIDGE NAME>” – again, I ran…

brctl addbr br0

Then add both our vxlan and our internal interface to the newly created bridge with “brctl addif <BRIDGE NAME> <INTERFACE> <INTERFACE>”

brctl addif br0 vxlan1 eth0

Now we can assign our internal IP that we wish to use for the internal lans gateway to our bridge, and then simply bring up our bridge and vxlan interfaces.  Lastly, I ran these commands…

ifconfig br0
ifconfig br0 up
ifconfig vxlan1 up

That does it for the Amazon configuration, the Google configuration is exactly the same, except substituting the Amazon public IP as our destination when adding the forwarding entry.  Once we do this you should be able to ping back and forth between the test client VMs, each located in their separate cloud.  Now think of the possibilities – nested ESXi in each cloud, with a layer 2 VM Network that stretches through the vxlan tunnel – pretty sweet stuff!

One thing that could be a PIA is that this config won’t persist across reboots.  I’ve tried in many ways to get the interfaces added to the persistent rules, but found the quickest way to get this to run on boot is to simply create a small bash script containing the commands; both Google and Amazons are shown below.

ec2script googlescript

Save each bash file in their respective /etc./init.d/ directories and make them executable.  I called the configVXLAN Then run the following on both Amazon and Google to ensure it gets ran on startup

update-rc.d /etc/init.d/configVXLAN defaults 99

And that is it!  A functioning stretched Layer 2 network between Google Cloud and Amazon EC2 using Ravello!  The possibilities are endless…  Again, I’m not a big networking guy, so if you know of any way I can improve this (use NSX?) just let me know…  Thanks for reading!

A Google Cloud to Amazon vMotion – The Ravello Way!

v2Ravello_Logo_largeToday Ravello Systems, a company based out of Palo Alto and Israel announced a new beta, a beta that I think is going to go over very well within the VMware community – one that will allow us to spin up vSphere labs, complete with vCenter Server, ESXi hosts, Domain Controllers, Storage and Network services and all the VMs that go with the punch inside of Google and Amazon’s cloud.  To be honest I was kind of skeptical when I first started working with Ravello?  I mean, come on, an ESXi host in Amazon, let alone and ESXi host running VMs inside of Amazon, an ESXi host running VMs with little to no performance penalty, all running within Amazon – you can see why I might of cringed a bit.  But Ravello gave me a shot to try it for myself – and during the introductory chat as they were showing me how things worked I thought, hey, what a use case for the new cross vCenter vMotion capabilities in vSphere 6!  A lab in Amazon, a lab in Google Cloud, and VMs migrating between them – how cool is that?

Who and what is Ravello Systems?

Now, before I get into the details of the vMotion itself I want to take a step back and explain a little bit about Ravello Systems themselves, and what they have to offer.  Ravello was founded in 2011 with the sole purpose of supporting and driving nested virtualization to the next frontier and did so when they launched their product globally in August of 2013 (You had to of seen the scooters at VMworld 🙂 )  They didn’t just want to simply provide an environment for nested virtualization though, they wanted to make it simple and easy for companies to replicate their data center infrastructure into the public cloud.  The core technology behind all of this is their HVX hypervisor – essentially acting as a Cloud VM, sitting in either Amazon or Google and providing overlay networking and storage to the VMs that are placed on top of it.


As per the diagram above the VMs present can be built from scratch or imported via an OVA within Ravello’s very easy to use intuitive interface – but perhaps more interestingly you can utilize the Ravello Import Tool(??), point it to your ESXi host or vCenter, and import VMs directly from your environment into the cloud!  But they don’t stop there, Ravello can also detect and create every network your VM is attached to, deploying an exact duplicate of your network infrastructure!  Now if this wasn’t good enough for you the beta today announces the ability to support Intel VT through HVX – which means we can now run VMs on top of ESXi on top of HVX on top of Amazon or Google!  True inception leaving us with a setup shown in the diagram below.


A great place to break things!

There is a reason why Ravello dubs their technology as having the ability to create “Smart Labs”!  Throughout my early access to the solution I broke and fixed so many things within my applications – and Ravello always gave me a way to rebuild or reconstruct my labs in a very efficient manner.

RavelloSaveToLibraryFirst up we are able to save our VMs to the library – which is essentially a personal set of VMs and images that we can re-use in all of our applications.  For example I only had to build my ESXi 6.0 image once – after saving this to the library I was able to simply drag and drop this VM as many times as needed to as many applications as needed, simply re-ip and re-naming after I was done.

RavelloSaveToBlueprintHaving the ability to re-use VMs is cool but the blueprint functionality that Ravello provides is really where I see value!  We are able to take a complete application, in my instance an ESXi host, domain controller, vCenter Server, etc and save the entire application as a blueprint.  Blueprints are then available to be used as starting points for new applications – meaning I can build a complete lab on Amazon, save as a blueprint, and then publish a new application to Google which is an exact identical copy, networks and all.  Blueprints are an excellent way to test out the different public clouds as well as version or snapshot your entire lab before making any major changes – if things go awry you can simply republish your saved blueprint to a new application.


Enough talk – Let’s see the vMotion!

Alright!  Let’s get to it!  Let me first warn you, the environment I built to do this was quick and dirty – not a lot of polishing going on here.

The two applications we will be using are Google-vxlan and EC2-vxlan – I’ll let you guess which public clouds each is published to.


As shown above these applications are pretty similar; each containing an Ubuntu server (used to establish the vxlan tunnel between EC2 and Google), a pfSense appliance that provides a VPN for my vMotion networks, a vCenter Server (the Windows version), and an ESXi host (just one for now).  The EC2 application also contains a jumpbox VM which provides entry into the local network as well as DNS services.


As far as networking goes the setup at both Amazon and Google is almost identical with the exception of the jumpbox.  The network is available at both EC2 and Google.  The network is the only network that is routed to the internet, therefore my only access into the labs outside of the Ravello GUI – this is why the jumpbox also has a connection to this network – to act as an RDP gateway of sorts.  The two Ubuntu servers have an elastic public IP attached to them in order to ensure the public IP doesn’t change and mess up my vxlan config.  The free trial of Ravello gives you two elastic IPs, and four other DCHP public IPs (subject to changing every now and then).  The vxlan tunnel is established between the two elastic IPs in order to provide Layer 2 connectivity between Amazon and Google.  The pfSense boxes each have a dynamic public IP attached to them with an IPSEC tunnel established between the and the networks.

vsphereshotOn the VMware side of things I have two vCenters with embedded PSCs (i know – bad practice) – one in Amazon and one in Google, which are attached to the same SSO domain and configured in Enhanced Linked Mode.  Therefore whatever is at Google can be seen at Amazon and vice versa.  As far as vMotion goes I’ve simply enabled this one my existing management interfaces (more bad practice – but hey, it’s a lab).  There is local storage attached to the ESXi hosts and one VM named EC2-VM1 present.

So my goal was to migrate this VM from Amazon to Google and back again, taking both the compute and storage with it.  Now just writing about a vMotion is not that exciting so I included a video below so you too can see it move 🙂  It’s my first attempt at a video and had some screaming kids while I made it so yeah, no narration – I’ll try and update with a little tour of the Ravello environment later 🙂

So there you have it – a VM moving from Amazon to Google and back, all while maintaining its’ ping response – pretty cool!

Is Ravello worth it?

esxi-home-labSo, with all this the question now remains is Ravello worth the cost?  Well, considering as how Ravello estimates the cost of a two ESXi Node, vCenter and Storage lab to be on average $0.81 – $1.71 per hour (usage based, no up front costs) I would certainly say it is!  The ability to run nested ESXi hosts on top of the public cloud provides a multitude of use-cases for businesses – but honestly I see this being a valuable tools for the community.  I plan on using Ravello solely for my home lab usage over the next year or so – it’s just so much nicer to break things and simply re-publish an application than it is to try and rebuild my lab at home.  If you want to give Ravello a shot you can sign up for the beta here – Even after the beta expires you simply swipe your credit card and pay Ravello directly – no Amazon accounts, no Google bills – just Ravello!  You will be limited during the beta’s and free trials in the amount of CPU, RAM and concurrent powered on VMs but they definitely give you enough resources to get a decent lab setup.

Ravello has a great solution and certainly expect more from me in regards to my lab adventures in the public cloud.

Disclaimer: Ravello gave me early access to their ESXi beta in order to evaluate their solution – I first signed up for a free trial and did get the amount of RAM and number of VMs available to me increased.  They didn’t however require that I write this post nor write anything for that matter, or provide any $$$ for anything that was written – these are all my words!

Veeam announces GA of Veeam Endpoint Backup

During their first inaugural VeeamON conference last October Veeam announced the beta of Veeam Endpoint Backup.  I wrote a little overview in regards to Endpoint Backup in case you need a refresher.  Now, Veeam’s Backup and Replication has long been infamous for being purpose built for the virtual data center, and Endpoint Backup is the companies answer to bringing the same great Veeamy-tech to your physical laptops and desktops.  Today, that announced beta has ended and Veeam Endpoint Backup is now generally available.

So what’s changed since the beginning of the beta?

VeeamEndpointA lot actually!  Being in beta for 6 months has really helped Veeam to ensure that they are releasing a genuinely, tried and tested, rock solid product into the market.  In fact, throughout the beta many of the new features now included in Endpoint Backup were suggested by users just like you and me on the community forums surrounding the beta.  Veeam, like always have done a great job taking into account user feedback and delivering a product that’s packed full of useful features and “just works”.  There are a lot of features to VEB and you can see them all here – but, I’d like to go over a few of my favorites.

Integration between VEB and VBR

Coupling Patch #2 of Veeam Backup and Replication (released later this month) alongside the GA of Veeam Endpoint Backup brings some awesome functionality of being able to monitor, control and restore endpoint backups within VBR.  By backing our endpoints up directly inside a Veeam backup repository we are now able to take advantage of many of the traditional VBR restore goodies with our physical backups.  Aside from simply file level recovery, application items, such as being able to restore SQL tables, Exchange and Active Directory objects – they can all be performed on our physical backups now as well.  Although the product is geared towards endpoints, meaning desktops and laptops, I see no reason why you couldn’t install it on some of those last physical servers you have laying around.  In fact, Veeam says themselves that although it isn’t built for servers it will work on Server 2008 and above.


Veeam has added the ability to export our physical disks from the backups directly into a vmdk, vhd, or vhdx file as well.  Now this isn’t a true P2V process, they aren’t removing any drivers or services or preparing the disk to be virtual in any way – this isn’t their intention.  This is simply another way to recover, another way to get the data you need – and honestly, if you wanted to try and build a VM out of these exported disks I’m sure there will be posts around the process out there in the next few months on how to do so.


In terms of security Veeam has added the ability for administrators to set access restrictions on their backup repositories.  What this does is allows us to grant access to certain repositories to certain users, while restricting access to others.

Aside from the new integration, Veeam Endpoint Backups which are stored in a Veeam backup repository can also take advantage of existing VBR features, such as encrypting your backups, traffic throttling, monitoring incoming backups, email status alerts and support for Backup Copy and Tape jobs to get those backups offsite.

It’s not just about B&R

Sure, the integration’s with VBR are pretty cool but they aren’t the only thing that’s included.   Yeah, we have all of the traditional endpoint backup features like incremental’s, multiple target options, and scheduling but it wouldn’t be a Veeam product without a few extra goodies baked in.  I’m not going to go in depth about them all, but listed below are a few of my favorites

Full support for Bitlocker drive encryption – This gives you the ability to de-encrypt your Bitlocker backups before restoring, directly from with the Endpoint GUI.

Ability to control the power state of computer post backup – If you have your computer set to backup at the end of your work day, you can leave knowing that once your backup has completed Veeam will, in true green fashion, power down your workstation.

Backup triggers such as “When backup target is connected” – Veeam will monitor for when you plug in that external USB drive or connect to the network that you have setup as your backup target and can trigger the backup process immediately there after.

Support for rotated USB drives – If you want to rotate your backups on one USB drive one week and another the next, Veeam Endpoint Backup can handle this for you, allowing you to backup to one drive while the other goes offsite.

On-battery detection – Backups can be automatically prevented from starting when Veeam detects that your laptop is running on-battery and contains less than 20% run time – ensuring VEB doesn’t chew up valuable power in your time of need 🙂

So what hasn’t changed?

freeWe talked about what has changed since the beta bits were first shipped in November but perhaps the most important and most cared about feature lands in the “What hasn’t changed?” category.  What hasn’t changed is that Veeam Endpoint Backup was put into beta as a free product and will remain free now that it is generally available.  Veeam has a long history of providing free tools for the community, they have Backup and Replication Free, SQL/Active Directory, Exchange Explorers are free, the old FastSCP which was free and now Veeam Endpoint Backup Free!  There should be no barrier to stopping you from going and checking out VBR for yourself.

Now in my VeeamON post I tried to determine the future of this product, where it would fit in, what features Veeam would add to it – and honestly I was way off on a lot of them – but one I was sure would come would be the integration with Backup and Replication – and it’s here now!  Do I think Veeam are done innovating in this area?  Absolutely not!  From my experiences Veeam is a company that never stops moving.  I’m excited to see Veeam Endpoint Backup go GA, and I’m excited to see what the future holds.