In part 1 of my vCloud Air test drive we went through the vCloud Air UI as well as went over the steps it took to get a VM up and running in the cloud.  This is all great except for the fact that our VM had no connection to the internet – nor did we have any way of accessing our VM outside of the default console that vCloud Air provides.  This section will deal with just that – we will explore the NAT and firewall rules that need to be setup in order to get our VM access to the internet as well as port forward our public IP in order to provide ssh access into resources within vCloud Air.

Just a note – If you wanted to try out vCloud Air On-Demand on your own you can do so by following this url – and using the promo code Influencer2015.  This will get you $500 in service credits to burn in 90 days – more than enough credit to give it a valid test.  This code and url expires June 30, 2015 so be sure to register ASAP – also, it’s valid only for new MyVMware accounts meaning you will most likely need to register under a different email than you currently use.

Just as I did in the first post in this series, part 2 will have a video an an accompanying blog post.  The video, embedded below along with the blog post both accomplish the same result – so hopefully I’m covering off everyone’s content type of choice!

Connecting our cloud to the internet

As we seen in part 1 our VM was not connected to the internet by default.  Thankfully accomplishing this task is not that hard, even automated to a certain extent inside of vCloud Air (notice a recurring pattern here?), basically creating the NAT and firewall rules that we need in order to allow communication out.

Speaking of NAT let’s get a little of the vCloud Air terminology straight before we continue.   First up is our firewall – the vCloud Air firewall essentially is closed by default, meaning all traffic both in and out from the public IP is blocked by default.  In order to change this, we create what’s called Firewall Exceptions.  How vCloud Air interprets NAT is always based on the internal vCloud Air network, as follows

• SNAT (Source NAT). – Deals with traffic originating from within the vCloud Air Network (source) destined for another network (ie Internet)
• DNAT (Destination NAT) – Deals with traffic originating from another network (ie Internet) destined for the vCloud Air network (destination).

Now before we can get into any natting or firewalling we need to create a public ip address to nat out of.  This is done by browsing to your gateway configuration and then the ‘Public IPs’ tab.  The actual adding of the IP is done by clicking ‘Add IP Address’ – tricky huh?

Once we have our public IP setup we can do one of two things – we can create the SNAT and Firewall exceptions manually or we can right-click our VM and selected ‘Connect to Internet’  The latter option will automatically create the SNAT and Firewall exceptions that we need in order to allow outbound access from our newly created VM.

Just a note here as well – I found it best to simply let the UI report back that everything has completed successfully – not just here but when doing things such as deleting VMs and creating data centers.  Sometimes navigating away from a page while a task was in process caused either the task to take and extremely long time or forced me to log back into the UI.  Anyways, after the task completes you should see the following rules that were created.

Now if you are wondering how to manually create a firewall rule don’t worry because we are going  to do this as well.  Although the rules have been created to allow http/https/dns out of our network there is nothing created around ICMP or ping.  This is a commonly used method of testing connection to systems, so I’m not sure why this isn’t included in the ‘Connect to Internet’ workflow.  Either way it gives us the opportunity to go through the process.  Simply clicking the Add button will allow us to configure the following rule, which allows ping out not only from our VM (109.2) but our whole 109.0 network out to our external IP (shown below).

At this point we are almost there in terms of access to the internet.  vCloud Air has statically assigned us and IP from our default IP pool, however it hasn’t done any configuration in regards to dns – so if you were to go try and ping google.ca at this point your VM would have no way of resolving it.  If you need to add some name servers to your Ubuntu VMs interface you can do so by running the following commands.

echo “dns-nameservers 8.8.8.8 8.8.4.4” >> /etc/network/interfaces

ifdown eth0 && ifup eth0

At this point, we should be successful in pinging google.ca or any other network address located on the internet – we have properly connected our cloud to the internet.

Connecting the Internet to our cloud.

Remember back in part 1 when I was griping a bit about not being able to send CTRL+ commands to my VM through the default console?  Well, one way around this might be to configure and allow ssh through our firewall, which would allow me to use putty or any other ssh client and issue CTRL+ to my hearts delight.  Keep in mind these scenarios would also work for Windows VMs and RDP by simply using port 3389 or whichever port you desire.

So, since our ssh traffic is going to be originating from the internet and destined to our vCloud network we first need to create a DNAT rule in order to port forward port 22 from our external IP to our internal Ubuntu server (Note:  The default Ubuntu image already is listening on port 22 for ssh).  The setup of the DNAT rule is shown below, remember to wait after clicking ‘Finish’ till vCloud Air reports success back.

Even though we have our DNAT setup now we still need to allow access on port 22 on our external IP through our firewall – remember everything is blocked by default so the following firewall exception will need to be created.  I’m left the source IP and port as Any/Any, essentially allowing access from anywhere – if you had a specific IP that you would always be connecting from you could technically be a bit more secure and use that.  For my testing though, I don’t care so much…

And there you have it!  After waiting for the rules to apply (just wait) you should know be able to open up putty or your favorite ssh client, enter in your external (public) IP and log in to your VM.  Any other services and ports you want to open up?  Just simply repeat the following steps using whichever port you desire.

Although writing all this down after the fact seems pretty self explanatory and easy, to be honest, I struggled a bit during the networking portion.  Not to say it isn’t intuitive, but with everything else being a breeze within the vCloud Air UI I would’ve thought there would be some pre-built workflows around opening up services given the number of steps it takes.  Even if it was just common items such as ssh, rdp, or www.  That said, it is possible that maybe if I RTFM it might have been a bit easier – but I like to jump right in – helps me evaluate the usability.

All in all VMware has a great service in vCloud Air On-Demand.  It’s a piece that was originally missing from their cloud offerings.  Having a pay-as-you-go service where you don’t need to fork out long term commitments or budget is key, especially when you think in terms of timely workloads, dev/test, etc.  In the end vCloud Air has impressed me – a clean UI, easy to use solution without breaking the bank!

Again, if you want to test out vCloud Air On Demand for yourself go ahead and get a new MyVMware account and sign up at this URL using the promo code Influencer2015.  I know I’ve mentioned this a lot over the past two blog posts but it will get you $500 in service credits and that’s more than enough to get a solid judgment on the service.  Honestly, who doesn’t want free things!  Thanks for reading/watching.

As a vExpert I tend to get a number of opportunities to evaluate different pieces of software and platforms – and as much as I’d like to simply look at every one I just don’t have the time to do so.  That said, when the vCloud team reached out with an offer to have a go at their vCloud Air On-Demand service I rearranged some of my priorities – partly because cloud is interesting to me, but mostly because they also gave me the chance to let my readers have the same opportunity!  VMware offers everyone $300 in service credits to evaluate vCloud Air On-Demand, but they gave me an extra $200 – and the promotional code to give you guys the same!  So, if you register at using this exact link – and use the promo code Influencer2015, you too can have a total of $500 in service credits to play with.  Just a note – you have 90 days to use up your credits before they expire – oh, and you need to register before June 30th, 2015 – so hurry!  Another caveat, this offer is valid for NEW MyVMware accounts only – so, ummm, uh, yeah, find another email to register with

On to the evaluation

So I’ve recorded a couple of videos in regards to what I’ve done inside of vCloud Air, the first one, attached just below this paragraph takes us through a little tour of the vCloud Air web UI, and shows us the steps to get our first VM up and running.

Now if you don’t feel like listening to my Canadian accenty, cold-infested, whispering (I had a house full of sleeping kids) voice I’ve written the process down as well.  Hey, we all learn in different ways right – some people like videos and others can’t stand them – so here’s both.

Judging a book by its’ cover

A simple, clean interface can go a long way when it comes to peoples reaction and opinions on the software that they use.  The vCloud Air team certainly kept this in mind when developing the UI supporting their on-demand service.  It’s very clean – showing only the basic information that one would really need to see to get a handle on their virtual data centers and VMs.  If you have ever used vCloud Director (vCD) you know just how many different tabs and options are available within VMware’s cloud offering – there are a ton of them, and I find the vCD interface cumbersome and hard to use.  It’s nice to see that VMware has taken some of the basic functionality that vCD provides, and abstracted it away to the vCloud Air UI – allowing their customers to perform common tasks such as power operations, network setup, and VM creation/snapshotting without having to ever set foot inside of vCD.

Let’s Cloud Bro!

Let’s get to it!  The first step after logging into the vCloud Air portal is to create a virtual datacenter.  Before we do that though we have to determine exactly what region we want to work in.  As shown below we have some options as to where we would like our virtual datacenter to be located – I’ve chosen Virginia for some of my testing – but if you are following along, chose one close to you.

To create our Virtual Data Center select the + icon next to the Virtual Data Centers label.  As you can see there isn’t a whole lot of configuration required in this step, simply a name.  Also you can see that each VDC allows for 50 VMs containing 130 GHz CPU, 100GB of RAM and 2TB of both SSD accelerated storage and standard storage.

At this point automation kicks in and our virtual data center is created.  Once it’s complete we can see that a number of components will be created and configured by default for us.  Selecting our VDC from the left hand menu and clicking on the ‘Networks’ tab we can see a number of these pre-configured items such as our public gateway IP address, the default gateway IP for our internal network, as well as the IP range that will be handed out to VMs within our VDC.  We can also create new networks from directly within the vCloud Air UI, however if you need to delve a little deeper into the services offered you can do so by using the ‘Manage in vCloud Director’ link in the top right hand corner.  This will open an already authenticated vCloud Director session where you can manage your networks and add services such as DHCP, load balancing, etc. Essentially all of the functionality that you would normally have when running a full instance of vCD.

In order to create firewall rules, nat rules, and assign an accessible public IP to our gateway we need to select our default gateway under the ‘Gateways’ tab.  Again, we can break out into a vCloud Director window here as well.   We will come back to this section in part 2 of this series to connect our VM to the internet and grant ssh access but for now its just good to know where this information is located.

Speaking of VMs let’s get on with the show here and get our first VM created.  This is done on the ‘Virtual Machines’ tab (Use the giant “Create your first virtual machine” button).  When creating a VM you can select from the catalog which has been provided by VMware, or by creating a catalog, uploading and ISO and creating your VM from scratch.  For the sake of this evaluation I just used the 32 bit Ubuntu server provided by VMware.

After selecting your VM from the catalog you can then name it and customize the cpu/memory/storage to your choosing.  vCloud Air will default these settings to their preferred amounts but you can change them using their respective sliders.  What’s nice about his screen is that you can see how s simple CPU, RAM and Storage change can affect your price per hour.  In my case, this Ubuntu VM with 1 CPU, 2GB RAM and 10 GB of accelerated storage is a mere 5 cents/hour – not bad

Once the VM has been created it should now be listed under the Virtual Machines tab.  Right-clicking the VM will bring up a context menu showing all the actions available, including power options, console access, snapshotting, etc..

Clicking on the VMs name within our list will also bring us into more details in regards to that VM.  The ‘Resource Usage’ tab showing estimated costs, ‘Settings’ tab showing various configurable items, and the ‘Networks’ tab showing the networking information for the VM.  As shown below we can see that our new Ubuntu VM has claimed the first address within our IP pool – 192.168.109.2.

Another important note about the ‘Settings’ tab is the ‘Guest OS Password’ section.   In order to login to our newly created VM we will need the root password.  This can be revealed by clicking ‘show initial password’.  By default, all the VMs from the default catalog provided by vCloud Air will prompt you to change the default password after first login.  Let’s make note of this password and go ahead and open a console to change it.

As we can see below the console provided by the vCloud Air UI is pretty barebones – allowing us to simply provide input to the VM and a button to send CTRL+ALT+DEL to the VM.  I found this a little frustrating at times, especially since I was using a Linux VM.  There were times where I had to direct a CTRL+C command to the VM but had no way of doing so, instead I had to proceed with a complete reboot of the VM.  An on-screen keyboard may be a better solution here.

At this point we are done with part 1 of my test drive.  My goal here was simply to get a VM up and running and we’ve certainly accomplished that.  So far my opinion around vCloud Air On-Demand is a good one – Aside from a little hiccup of trying to send CTRL+ commands to the VM through the built-in console everything else has been a breeze.  I really like the UI – how they have taken some of the complexity involved with trying to certain tasks within vCD and provided a one-click, automated solution without ever having to touch vCD – yet still giving users the option to move into vCD if needed.  In part 2 we will have a look at setting up some of the networking and firewalling in our virtual data center – things will get a bit more complicated as we explore the NAT and firewall rules inside our gateway.

If you have any experience or thoughts about vCloud Air I’d love to hear them – leave a comment below or find me on twitter.  And as mentioned before if you wanted to evaluate vCloud Air On-Demand yourself go ahead and register here, using the Influencer2015 promotional code to get yourself $500.00 in service credits.

Don’t forget to read Test Driving vCloud Air On-Demand Part 2