Home > Blogs > VMware vCloud Blog > Tag Archives: vApp

Tag Archives: vApp

How to Build a vCloud vApp DMZ

By: Chris Colotti

This is a repost from Chris Colotti’s blog, chriscolotti.us

Okay I admit sometimes I spend too many late nights coming up with some goofy ideas.  However this one actually panned out as a real world vCloud Director Networking example where you can use to see how flexible vCloud Director Networking can be. The idea started from me wanting to rebuild my WordPress installation from a single server stack to a distributed two server Apache Web and MySQL setup. Pretty standard use case for a two server setup. Now I will NOT be covering the installs, setup etc of the applications here, maybe that will be another day.

The idea was to have a single vCloud vApp with two virtual machines in it. That itself is pretty easy and you can see below the single vApp container with the two virtual machines.

Let’s take a look at the network diagram below so I can explain what I got set up and working.

What we see is that the Web Server is connected to the 1743-Public network, which is what my Organization network provided for me. That’s an easy enough one to understand for sure. You can also see the three basic firewall rules needed below for web access to the server for HTTP/SSL/SSH. It goes without saying that there is an external IP assigned on the internet side of the Organization Network as well.

Next we can examine the virtual machine view and see that the two virtual machines are in fact connected to two different vCloud Network interfaces.

Note that the MySQL virtual machines also have an External IP Address assigned. This is done automatically by the vApp vShield Edge when the virtual machine is assigned to it, which we will see next. The vCloud vApp Networking tab is where we can see that the vApp network was created before assigning it to the MySQL virtual machine. Note that the ‘Always use assigned IP Addresses…” check box is enabled. This is important because when you power cycle the vApp, you want to maintain the networking! You can also see that the vApp Network is attached to the Provided Organization Network so it will route outbound to the internet for patches and updates.

This is where the really cool part comes in. We now have a Web Server connected to the org Network with an External IP and three firewall rules. We need to now allow the Web Server to connect to the MySQL server on Port 3306 and SSH so we can manage it from the  Web Server and connect to MySQL. That’s as easy as writing two rules in the vApp Network Firewall.

These rules basically show that ONLY the Web Server IP Address can access ONLY the MySQL Server IP Address on Port 22 and 3306.

Solution Summary:

What this simple example shows is that you can create a single vApp in a flexible way, but also create a vApp based DMZ for virtual Machines as part of that vApp. Provided the N-Tier servers only need to be accessed by the first tier, this works really well and now I have a setup where only the Web Server is exposed to the internet, yet the MySQL tier is again protected by its own firewall. What this really shows you is that as vCloud Administrators and Application folks, we need to not only understand networking, but now routing, and firewall rules as well. This structure is no different from if these had been physical servers in a data center on physical switches with hardware firewalls between them.

This shows a great use case on a small-scale of what you can do for a real word application. How do I know it is a real world scenario? You are reading about it hosted from these very two servers shown in the diagrams. Pretty cool right? Next will be duplicating the setup in a second cloud connected by vShield VPN between Organization Edge Devices and putting MySQL Replication in place with a backup Web Server….just for fun.

Some may ask why I did all this with a small set of WordPress sites that only get about 900 hits a day….. because I can…..that’s why….and it’s a fun learning experience.

Chris is a Consulting Architect with the VMware vCloud Delivery Services team with over 10 years of experience working with IT hardware and software solutions. He holds a Bachelor of Science Degree in Information Systems from the Daniel Webster College. Prior to VMware he served a Fortune 1000 company in southern NH as a Systems Architect/Administrator, architecting VMware solutions to support new application deployments. At VMware, in the roles of a Consultant and now Consulting Architect, Chris has guided partners as well as customers in establishing a VMware practice and consulted on multiple customer projects ranging from datacenter migrations to long-term residency architecture support. Currently, Chris is working on the newest VMware vCloud solutions and architectures for enterprise-wide private cloud deployments.

[How To] Get Started with vCloud Connector 1.5 – Part 2

By: Chris Colotti, Consulting Architect with the VMware vCloud Delivery Services team

This is a repost from Chris' personal blog, ChrisColotti.us

Ccolotti2_vcc1

In Part One of this two-part series, we examined the deployment of vCloud Connector 1.5, the architecture, and the options for accessing the user interface through the vCloud Connector Portal or the vSphere Client.  Here is a quick review of some key points to remember if you read part one previously.  Part two will focus on the actual moving of your workloads so you can see just how easy it is once you have it setup.

  • Deploy the vCloud Connector Server on Premise initially
  • Deploy vCloud Connector Nodes to all connection points you need access to
  • Provider clouds like Virtacore will have a single portal, but multiple actual clouds
  • The vCloud Connector Server today does not work behind NAT, so deploy on a local subnet
  • On Premise components can live outside the cloud, hosted nodes will be inside the provider cloud
  • Configure server and node passwords and create real Certificates for SSL between server and node
  • Using the portal still requires you have local access to the vCloud Connector Server via LAN or VPN if it is hosted on premise

Once you have the components all setup the fun can begin in moving the workloads.  Something to remember and consider is these are full network copies of the Virtual Machines.  They must be shut down in order to migrate them between vSphere, or your various vCloud setups.  Also if you have not read my series on the Clone Wars, it may be useful since some of the data around copying to and from transfer spaces is interesting.  If you have not let’s take a quick look at the process that vCloud Connector does to facilitate the moves.

  1. The Virtual Machine is Exported from the source location and temporarily stored on the vCloud Connector Node’s local space
  2. Once the export has completed from the source an import is initiated to the destination
  3. If the destination is a vCloud infrastructure, the data will be moved through the vCloud Cell’s “Transfer Space” located at /opt/vmware/vcloud-director/data/transfer
  4. The imported Virtual Machine will then be placed into the vCloud Director instance as a new vApp and the transfer space will be cleaned up.

The reason the Clone Wars series is important is to understand that on a local private cloud the transfer between vCloud, the transfer space and the final storage on ESX is all network copy based.  On a provider cloud like Virtacore or others, you will also have that copy going over the internet.  So basically, these things can take time to move.

Moving Your Workloads

I want to point out a couple of key changes from vCloud Connector 1.0 and 1.5 as it works today.

  • You MUST have Organization Catalogs available in order to copy between clouds.  

  • The underlying vCloud Director import/export functions use the catalog as a transport mechanism.  
  • If you do not have any Organization Catalogs you will not be able to copy.  In the situation with public cloud providers you may need to have one created if there is not one present.  I actually found this with Virtacore, but my account was created a while back.  New accounts should be coming with at least one catalog on your Organization to facilitate this.  If there is not one just contact the support chains for your provider.

The process is multi-step where vCloud Connector 1.0 did some of the steps for you.  What I mean is you have to do the following to get a vApp workload completely moved from one cloud to another.

  • Copy the vApp to the remote vCloud Catalog
  • Deploy the vApp from the Catalog using vCloud Connector or the vCloud Portal
  • Configure and test the vApp now in the new Cloud
  • Remove the Catalog item if you do not need it going forward

This may seem like more steps than with vCloud Connector 1.0, but this actually allows you to re-deploy the vApp should you have to for any reason before you remove it from the Catalog.  Only once you are sure you’re vApp is in the new cloud and functioning will you want to clean up and remove it.  This way you don’t have to do the entire process again.

From vCenter to vCloud

At this point in the game we will assume you are ready to move some workloads around.  For my test purposes I created an empty test VIrtual Machine on vSphere with a VERY small virtual disk, and no operating system installed.  I did this purely to see the movement, and not have to wait for 20 or 30 gigabyte to copy.  Below is the screenshot of all my clouds I setup in Part One, so the first thing to do is move a template from vSphere to my local vCloud Director.

Ccolotti2_vcc2
First we expand the vCenter object and locate the test template I created directly in vSphere by selecting the vCenter, then making sure I am on the template tab since this test object is an actual vCenter Template.  It is worth noting as well that this vCenter is actually the vCenter appliance, so that also works with vCloud Connector.

Ccolotti2_vcc3
If you want, you can also deploy this from vCloud Connector, but we will copy it to my local on Premise cloud first then move it to the public cloud.  When we select “Copy” We are given the options box.

Ccolotti2_vcc4
Now we can also select the VDC import.

Ccolotti2_vcc5Now we can also sect the Catalog for the import and select “Copy”.

Ccolotti2_vcc6
What we see is that the copy exports from vCenter and completes the import to the vCloud Catalog.

Ccolotti2_vcc7 Ccolotti2_vcc8

With a refresh of the vCloud connector view we can see the template in the catalog of vCloud Connector’s interface and we are ready to deploy it for use by selecting the deploy option.  However, I will jump over to moving a workload from a Private vCloud to a public vCloud as that may be more interesting.

Ccolotti2_vcc9

From Private to Public vCloud

Now comes the fun part.  As before I am using my Virtacore vCloud Express account to move the workload from my on premise vCloud to the Public vCloud.  The process is similar to the vCenter move, but now we are going vCloud to vCloud via the internet instead of local network.  Remember that depending on your provider you may have multiple vCloud’s behind their portal as is the case with Virtacore.  Therefore if you have a true template, you may want it on both vCloud’s for local deployment.  If your workload is an actual vApp, you can decide which cloud you want to run it in.  Again you need to ensure you have a Catalog available in both your provider based vCloud’s for this to work.

First we select the “Production” workload from the local Private vCloud on premise and copy it to the remote vCloud Catalog.

Ccolotti2_vcc10
The same as before only now you see the source is my local vCloud and the target vCloud is the Virtacore Los Angeles in my Public vDC on my Organization Catalog.  We also see in the vCloud Connector interface the progress of the copy.  As a reminder, I am using a test Virtual Machine with only a 25MB virtual disk to make this go quicker for test purposes.

Ccolotti2_vcc11

Once this process is completed, I could run another copy from my on premise to the remote vCloud to have this same vApp available on the Virtacore Virginia vCloud Express location, or I could copy it from the LA to VA vClouds and let theVirtacore network handle the transport.  Instead I am going to simply deploy it to the LA vCloud.

Ccolotti2_vcc12
Here I get my options for deployment to the vCloud in LA so I can deploy it from the Catalog.  I can select my vDC, name the vApp, as well as select the network from the options available.

Ccolotti2_vcc13
Once deployed it will show up in the Virtacore portal as a new vApp for me to power on and manage as I see fit.  I did find out the Virtacore portal does have a caching setup so it may take a couple of minutes for it to show up, but it will.

Ccolotti2_vcc14At this point I can configure my vApp and when I am done I can use vCloud Connector to remove the version of the template in the Catalog.  Again you may want to have a copy in your other hosted vCloud for future use, or you can remove it completely

Summary Review

What all this testing has shown me is that the combination of a hosted provider like Virtacore along with the vCloud Connector architecture provides a pretty powerful way to move workloads between clouds.  There are a few things you need to understand and get used to in the way of the architecture, user interfaces and other aspects.  Once you nail those down you can start copying workloads between your clouds and at the very least get copies of your templates and vApps into a public cloud provider to experiment.  What this has also done is allow me to take feedback of my findings back to the vCloud Connector team as feedback to possible adjustments in the future.

The key to remember is this is slightly different from the 1.0 product in the sense that you have to copy, deploy, and remove the vApp and that Catalog’s are required to facilitate the moves.  As with Part One, I wanted to thank Virtacore for being kind enough to provide me the public cloud space for this testing, and let you know they are offering $50 off the initial use of their vCloud Express product so folks can give it a shot.  Just use the code STEKREF when you sign up to get the offer if you sign up and check out their new portal as well.

Chris is a Consulting Architect with the VMware vCloud Delivery Services team with over 10 years of experience working with IT hardware and software solutions. He holds a Bachelor of Science Degree in Information Systems from the Daniel Webster College. Prior to VMware he served a Fortune 1000 company in southern NH as a Systems Architect/Administrator, architecting VMware solutions to support new application deployments. At VMware, in the roles of a Consultant and now Consulting Architect, Chris has guided partners as well as customers in establishing a VMware practice and consulted on multiple customer projects ranging from datacenter migrations to long-term residency architecture support. Currently, Chris is working on the newest VMware vCloud solutions and architectures for enterprise-wide private cloud deployments.

vCloud Director 1.0.1: Networking Samples

By: Massimo Re Ferre', vCloud Architect

This is a repost from Massimo’s personal blog, IT 2.0 – Next Generation IT Infrastructures.

My old vCloud Director Networking for Dummies post is still going strong according to my blog statistics. I believe this is an indicator that people are looking for more information about this topic so I thought I’d give it a little bit more color and create a few real life examples on how this theory works in practice. I suggest you read the Networking for Dummies post linked above before you dive into this one.

Note also that the other post as well as this one are based on vCloud Director 1.0.1, which is the latest release available as of June 2011. Things may change in the future so, if the vCD release you are using at the time you read this is above 1.0.1, chances are that things could be slightly different. I can’t really say more than that at this point.

Last but not least, everything I will be doing below can be done as a cloud consumer in self-service mode. As a matter of fact I will be doing everything as an Org Admin.

Introduction

To walk through an actual implementation of the networking stack I’ll use my IT20 organization hosted in the Stratogen cloud. This discussion starts with the description of the networking plumbing in my vCloud organization. From the vCD UI it looks like this:

Massimo 1
From a logical perspective it looks like this:

Massimo 2 

My Org has four public Internet addresses that Stratogen associated to my “Routed Network” when they created the tenant. For security reasons I am not going to widely advertise them in this post.

You can see these assigned addresses if you right-click on the Routed Network and select “Configure Services“:

Massimo 3

The last piece of the puzzle is three vApps I have created in this Org and that we are going to connect to the various networks you have seen above. This is supposed to give you a practical idea on how things can be configured. The names of the vApps should be self-explanatory.

Massimo 4

Direct Internet Connection

Let’s start with the most simple of the networking scenarios. Note there is a vApp called “Turnkey_Internet” which is comprised of a single VM. That VM is connected to the “Direct Internet” connection available in my Org. I have only one comment for this example: scaring! Never do this because you are in fact plugging your VM directly into the Internet without any level of protection (other than what you could have inside the Guest OS of course).

This is how my VM is configured:

Massimo 5

And this is how the VM fits into the logical network view: 

Massimo 6

The way this works is pretty straightforward and, if you read the vCloud Director Networking for Dummies post, it should be explained there. Basically the cloud administrator has configured a pool of available IP addresses for this “External Network” (since this is a vSphere PortGroup with native Internet connectivity this pool will contain native Internet IP addresses). Since the Direct Internet connection in my Org is nothing more than a pointer to this vCD External Network which in turns is a pointer (with metadata) to the PortGroup backing it, the result is that the vNIC of my VM gets connected directly to this PortGroup. vCD assigns the (vNIC) an IP in the pool.

I am glad Stratogen configured this network for me – as it is handy if you are experimenting with vCD networking – but in a real life scenario you would never want to connect VMs to a connection like this (directly connected to the Internet). However this may become pretty interesting if you, as an Enterprise, are using virtual data centers hosted in a cloud where the Service Provider has configured an MPLS connectivity back to your headquarter. Something like this: 

Massimo 7

It goes without saying that, in doing so, you are effectively dedicating an External Network (and in turn a PortGroup) to the IT20 Org. If for any reason you give access to another Org to the same External Network (either <Direct> or <Routed> – see next section) you are essentially giving the other Org access to the IT20 MPLS network.

Routed Network – single-tier vApp

This is where things start to become more interesting, slightly more difficult to explain and accomplish at the same time. I have another vApp that is called “Turnkey-Routed”. It contains a single VM that is connected to the Routed Network available in the IT20 organization. You can imagine this Routed Network as a dedicated layer 2 segment protected by a firewall device (vShield Edge). For more information on how this work from a vSphere perspective read the vCloud Director Networking for Dummies post. Essentially the VM in this vApp gets assigned an IP address available in the pool defined for this layer 2 segment. This is how vCD shows the details of the Hardware Properties for this virtual machine:

Massimo 8

And this is how it logically fits into our diagram:

Massimo 9

Note that in the diagram above we went a couple of steps forward. Not only we are protecting the VM with the Edge: I have also configured the Edge to NAT the private IP. To do so I have created a one-to-one mapping rule to one of the four Internet addresses Stratogen assigned to me. I have also configured a firewall rule to only allow traffic on port 12320 to reach the VM (this is because the Turnkey appliance uses particular ports to get access to SSH and web admin interfaces). How did I do this? Move onto the Routed Network and right-click on Configure Services. Point to the “External IP Mapping” tab and configure the NAT rule:

Massimo 10

You would then point to the “Firewall” tab where you can configure the firewall rule I have described above (as an example).

Massimo 11

I have just blocked all traffic coming into this VM except for traffic directed to port 12320. Easy.

Routed Network – multi-tier vApp

The single-tier vApp is still pretty simple. Let’s now focus on the third vApp I have mentioned. This is the “2Tiers” vApp, which is comprised of a front-end Windows VM (Win-Web) and a back-end Linux VM (REHL-DB). The idea is to provide IT20 customers with access to this application protected by multiple levels of security. The first step is to connect the front-end to the Routed Network in the Org and NAT it. This is similar to what we have already done with the single-tier vApp discussed above. I am not going to show screenshots of the NAT and Firewall configurations because the steps are very similar. It goes without saying that the Win-Web VM has a different private IP and I will be using another public IP to create the DNAT rule. This is how the logical layout looks like for this specific vApp. I am opening port 80 for this example:

Massimo 12

As you can see the back-end VM is not yet connected to any network. As I said we want to provide an additional level of security for that VM and we don’t want to connect it “directly” to the Org network. How do we do this? This is where the so called “vApp Networks” come into place. You can imagine vApp Networks as layer 2 network segments dedicated (and only available) to the specific vApp they have been created for. In other words a vApp Network created for one vApp cannot be used by any other vApp. If you want to know more about this concept please refer again to the vCloud Director Networking for Dummies post.

You can create vApp Networks in multiple ways but the easiest one is to click on the “Add Network” choice in the drop-down menu for the vNIC connectivity available in the Hardware Properties of the VM: 

Massimo 13

Selecting it kicks off a brief wizard that asks you the very basic metadata to create a new network (Subnet Mask, Default Gateway, IP Pool etc). You can then select whether you want to protect this dedicated vApp Network with NAT and Firewall functionalities. You can do this in the Networking tab when you “Open” the vApp: 

Massimo 14

Let’s pause for a second here (too many screenshots to digest).

Don’t be fooled. What we are trying to do is to create a logical layout like the one depicted below: 

Massimo 15

In a way we are applying to this vApp Network the same NAT and Firewall principles that we applied to the Routed Network at the organization level. Where do you configure these rules for the Edge device that is backing this vApp Network? Easy. Look at the latest screenshots above and click Details. Done.

This is the tab where you configure the NAT rule so that the DB private IP gets mapped to the Routed Network in the organization: 

Massimo 16

Below is the tab where you configure the Firewall rule to allow DB traffic only (this rule is just an example):

Massimo 17

Conclusions

Let’s now try to put all these pieces together and look at how the logical layout of the workloads running in the organization looks like as a whole:

Massimo 18

As you can see the self-service networking stack in vCloud Director is pretty powerful and flexible although there are certainly things that could (and should) be done better. For example you may argue there is a lot of NATting going on (and I would have a problem arguing the opposite). But, as we said, this post is based on the 1.0.1 version of the product and things may change in the future.

Note that we haven’t covered any example on how to use the “Internal Network” since it should be pretty straightforward. It’s basically a flat layer 2 network that doesn’t go anywhere and only allows VMs attached to it to communicate to each other.

I hope you found this post useful. I’d like to get your feedback.

Massimo currently works as at VMware as a Staff Systems Engineer, vCloud Architect. He works with Service Providers and Outsourcers to help them shape their Public Cloud services roadmap based on VMware cloud technologies. Massimo also blogs about Next Generation IT Infrastructures on his personal blog, IT 2.0.

Cloud Hosting With VMware

By Karl Robinson, Managing Director at StratoGen

I often get asked what’s so great about cloud hosting with VMware when there are so many different cloud hosting platforms available. The beauty of the cloud is that I can always reply with ‘try it and see’, as it’s so easy to take a free trial on a VMware cloud hosting platform for a few days.

I guess one of the key things about vCloud Powered solutions are that they are single vendor end to end – from the portal to the back end.  Many other cloud offerings have ‘home grown’ integration into the hypervisor, which works fine, but presents ongoing compatibility challenges as the differing technologies evolve.

Behind the scenes you expect VMware to offer superior availability and performance, but how easy is the platform to use in real life? Just how do you deploy a VMware virtual machine in the cloud?

If you’re new to VMware, the first thing to know is that most of the VMware cloud hosting providers will use vCloud Director (vCD) as the user interface. vCloud Director allows them to present you with a virtual datacentre in the cloud, into which you can build and deploy your virtual machines, create networks and even assign firewall rules. Logging in to your virtual datacentre for the first time can be a little daunting – so let’s cut to the chase and walk through the basic steps to get your first virtual machine up and running.

If you would like to try VMware cloud hosting then please click here to take a free trial.

I’m going to assume that you already have a Virtual Datacentre (vDC) allocated to you by your VMware hosting provider. Assuming you do, you should have a unique URL to access your vDC, and a username and password, so first things first; you’ll need to log in:

Stratogen1
Once logged in, you’ll be taken to the ‘home’ screen welcoming you to your cloud.  On the home screen, click on the ‘Build new vApp’ link:

Stratogen2

A vApp is essentially a logical collection of virtual machines and networks – it is a self-contained entity which can be moved, copied or saved into a catalogue to simplify future provisioning and maintenance.  This functionality is extremely valuable if you regularly deploy the same type of environment.  You can’t deploy any resources in your cloud without first building a vApp.  So once you’ve clicked the link, you’ll be presented with the ‘vApp Wizard’:

Stratogen3

The wizard will give your vApp a default name, using the convention ‘vApp_yourusername_#’ – # is a sequential number – each time you build a vApp the number will increment by 1.  So in theory you don’t need to rename your vApps, but you might wish to change the name to something more meaningful, based on the role of the vApp for example – if so, simply over-type the name.

I usually ignore the ‘Runtime Lease’ and ‘Storage Lease’ options – you can set your vApp to expire – for example if you are running a short term project, you can set the ‘lease’ for the duration of the project, and your resources will be automatically erased at the end of the lease.  Most customers choose not to do this – if your project shifts and you forget to change the lease, you could wind up in trouble!

Click next in the wizard to move to the next section where you can add virtual machines to your vApp.  You now have a couple of options – you can either choose to deploy a virtual machine from a ‘catalogue’ or deploy a new virtual machine from scratch.

Stratogen4

To keep things simple for this first post we’ll go for the catalogue option, but in the next post of this series I’ll talk you through doing it from scratch.

vCD has 2 levels of catalogue – ‘My organisation’s catalogs’ and ‘Public catalogs’.  If you’re a new user, your Organisation’s catalogue will be empty – in post 2 of this series I’ll show you how to create and populate your own catalogue, but for now I’m going to select the public catalogue option.  The StratoGen public catalogue contains a selection of virtual machine images with various preinstalled operating systems:

Stratogen5

I’m going to select one CentOs 5.5 virtual machine template with LAMP (you can select multiple machines at this point with different Operating Systems if you need to), then click on the ‘Add’ button and then ‘Next’.

In the next step of the wizard you can connect your virtual machine to the network.  My vDC currently only has one network available to it – a Direct Internet connection.  This connection will have public static IPs which it will allocate to the machines I provision.  There are many different networking scenarios possible within vCD which I’ll cover in later posts – for now a Direct Internet connection will suffice:

Stratogen6

Next you can choose the network settings for your VM – by default it will be set to allocate a static IP address from the network pool – most customers choose to use the default but if you want you can allocate a specific IP from the pool or set the box to DHCP:

Stratogen7

You’re almost done deploying your first vApp – click next and then next again (skipping the ’configure networking’ step) which will take you through to the ‘Ready to Complete’ screen:

Stratogen8

Check the details and when you are happy click ‘Next’ and you’re done deploying your first vApp!  It will take a little time to create, depending on the number and size of templates you’ve chosen to deploy – you can see the provisioning progress by clicking on the ‘My Cloud’ button and watching the progress bar in the vApps view:

Stratogen9

Once the provisioning process has completed, you’ll need to power on your vApp before you can use it – you can do this by clicking the green ‘play’ button:

Stratogen10

To access the newly provisioned virtual machine, you can use the VMware console tool by simply clicking on the machine icon which will pop up a browser based console window (an installer will run the first time you do this and you may need to allow popups in your browser):

Stratogen11

Before logging on for the first time you’ll need to check the password that has been allocated to the VM by the ‘Guest Customisation’ process.  Click on the VMs view then right click on the machine and select properties:

Stratogen12
You’ll find the password in the ‘Guest Customisation’ tab:

Stratogen13

That’s it! Your first machine is now live on the cloud, connected to the Internet and you’re ready to go!

The vApp we deployed is a simple one to demonstrate how easy is to use vCD, but a vApp could be as complicated as you like consisting of a multi-tiered architecture with middleware servers, application and database servers of mixed OSes all complete with appropriate networking.

About StratoGen

Karl Robinson is Managing Director of StratoGen, a leading cloud hosting provider with a worldwide client base. You can follow StratoGen on twitter, or read more on the StratoGen blog.

Update on Virtacore vCloud Express Beta

Matthew D. Sarrel, Sarrel Group

I’ve been playing around with the Virtacore vCloud beta for a few weeks. There isn’t all that much that I can do with it right now.  Even with the limited functionality though, it does what they say it does – which is pretty good for a beta cloud offering.

I got another email from Virtacore:

Greetings to all of our vCloud Express Beta Testers!

The last several weeks have been pretty busy behind the scenes here at Virtacore.  Thanks to feedback from our testers, we believe we've isolated a few problems encountered during testing.  Specifically we believe we've finally pin-pointed and corrected the issue that was resulting in VMs suspending after running for a week.  This fix will be applied to all new VMs created going forward and as of early Monday morning is now fixed for all existing VMs. 

In addition to fixing bugs and troubleshooting interface errors, our development team is in the process of rolling out two new features – user management and vApps (aka VM Groups). 

You can find a more detailed explanation of the features here.

And on a final note, we are extending our vCloud Express beta program through February 15, 2011.  There are a few more bugs/features we want to work through before release, so we're pleased to announce you'll continue to have access to the beta until at least February 15th. 

I did have that problem of the VM suspending on its own, but I didn’t think it was such a big deal because I’m not using it for anything anyway.  When I signed up for the beta, Virtacore suggested that I not save any data on the VM because it is beta and that they could blow it away as part of the development process.

Virtacore had also been running a competition to see who could report the most bugs.  That ended, but had I participated I could’ve won a $50 Amazon gift certificate. It’s an interesting enticement to get people to test and report findings.

I’m getting more and more eager to get out of beta and get some real systems running up there.

Update: Virtacore also recently rolled out the ability to build a vApp.

A vApp is basically a group of virtual machines with applications and operating systems running on top of them, stored with the information needed to launch and operate them. I think of vApps the same way that I thought about “teams” in VMware Workstation.  Many organizations have moved beyond thinking about VMs and now think in terms of vApps in order to simplify complex multi-server environments.

VApp1

Creating a vApp is about as easy as creating a VM:

  VApp2

And then the vApp can essentially be managed as a “Server Group”

VApp3

Stay tuned for more updates as Virtacore's vCloud offering continues to evolve.

Matthew D. Sarrel (or Matt Sarrel) is executive director of Sarrel Group, a technology product testing, editorial services, and technical marketing consulting company.  He also holds editorial positions at pcmag.com, eweek, GigaOM, and Allbusiness.com, and blogs at TopTechDog.