Virtualization of Enterprise Systems – vApps

Back to Virtualization and Cloud Index

In my first post in this series I described the primary building blocks in a virtual deployment of a complex enterprise solution. Basically, you run your applications on virtual servers (VMs) which are bundled together into logical collections of VMs to represent a solution (a vApp) and these are managed using vCloud Director.

The key building block when building up virtual enterprise solutions is the vApp. If you look back at the table on the primer posting you’ll see that a vApp is a “collection of VMs bundled up with the associated network relationships and policies which can be replicated, distributed and deployed to represent a typical server collection”. Hopefully you get the general idea – a vApp is a way of packaging Virtual Machine Images into logical packages that represent something useful…”but”, I hear you say, “please tell me more” and tell you a little more I will.

Let’s start with a standard, everyone loves a standard. OVF – (DMTF’s Open Virtualization Format) is a standard that allows vendors to put their virtual machines and associated bits into a package. There are many different products that allow you to create vApps including the aforementioned vCloud Director. A completed OVF file contains:

• The actual Virtual Machine images.
• Mandatory and optional metadata for the content - product name, build number/date, etc.
• Information about the virtual environment - virtual hardware information, virtual drive details, OS details, network topology, VM startup/shutdown order/actions.
• Additional supporting information – deployment options, EULA, product information, localization, and general annotations for upgrade instructions, etc.

So now you have a nice encapsulation of not just the VMs but all of the pieces that are required to support them running as a group regardless of the vendor. The OVF package can be electronically signed and supports compression.

So, what use is a standard in this case? Well, packages that conform to the OVF standard can be deployed onto any OVF-compliant hypervisor, (in the primer I explain briefly that the hypervisor is the layer that emulates the actual hardware and allocates resources to the VM image). So in theory (and in practice I guess) you can create your vApps and then distribute them out into different environments.

I’m aware that I am not answering the ‘why should I care?’ question yet but bear with me. I’ll write-up the vCloud Director piece, expand on some of the other elements and then once we are all on the same page we can dive into that question.

Comments

[Douq Millar]

If vApps are essentially a template to stamp more instances of virtual configurations, how then does update occur? One of the many potential advantages of vApps is that configurations are standardized, all with fresh updates and patches, so that support is easier (every customer doing same thing, hitting same issues, nothing occurs due to unique configurations).

Does updating the vApp update the derived instances or does each instance have to be maintained separately?

I'd think a structure where software image is shared between all instances, but data is unique would do the trick - oh yeah, isn't that multi-tenant?