vCloud Director: Catalog Experiments

calendar Sep 30, 2010 · 11 min read  ·
Share on: linkedin copy

One of the promise of cloud computing is the simplification through standardization of deployments. A major role in this is played by the vCloud Director Catalog. In vCloud Director version 1.0 the catalog is a collection of vApps and media files. If you are familiar with vSphere think of vApp templates as vSphere VM templates on steroids: not only you can group more VMs together and capture them into a catalog as a single entity, but you can also set startup priorities, shutdown policies and things like that. As far as media is concerned we are essentially talking about ISO files (even though floppy images are supported as well for the records). Note these ISO files can either be OS installation ISOs or they can be applications distributed on a CD or DVD and that can be installed on top of an existing OS.

Many of the service providers I am working with would like to explore in more details how they can leverage the catalog for at least a couple of use cases:

  1. They would like some of their ISV partners to capture into a vApp template standard deployment patterns of their applications so that these can be bought and used by the service provider's end-users
  2. They would like to allow their end-users (aka Public Cloud consumers) to be able to install an OS from scratch

The use case #1 is really an interesting new business model. This is a win-win situation for both of the players since the service provider becomes a sale channel for the ISV application and the ISV becomes a sale channel of the service provider IaaS service. I don't want to derail the discussion so I'll defer to another post the discussion whether this is to be considered pure SaaS or just IaaS pre-loaded (I say it's the latter).

The use case #2 can hardly be associated to the concept of standardization of deployments, yet it is part of the enormous offering flexibility service providers want to have and in turns offer to their customers.

Before we get our hands dirty let's start with some principal around the vCD catalog. First and foremost you need to be aware that there isn't a "cloud-wise public catalog" object. Having this said vCD has an option to publish an Organization Catalog to other organizations (or tenants). So in my lab I have configured two organizations. The first one is called ISV1 and represents (virtually) one of these strategic partners the service provider may want to work with. Note that, from a vCD perspective, ISV1 is just a normal organization (similar to what you'd create for a standard consumer of your IaaS services). However this organization has a few peculiarities:

  • Their catalog is Published making it, in practice, a global catalog available to all organizations. This differs from other more typical organizations where their catalog is likely kept private for internal consumption (Coke, as a cloud consumer, may not want to publish their catalog to Pepsi and viceversa)
  • The Org vDC(s) associated to this organization are largely used to host catalog items. In other words the "My Cloud" of these type of organization would be empty most of the time (unless it's used to instantiate vApps to be then captured into the organization published catalog)

In my test scenario I have created another organization called SMB1. This represents the typical service provider's end-users that may be interested in consuming a pre-packaged application from ISV1. Note I have associated this model to an SMB customer since I thought this would make more sense for that segment of the market. Interestingly enough I have had inputs that this may be a business model that may appeal some enterprise customers as well for specific verticals.

With all this being said, here it is what I created on my vCloud Director lab setup:

A few things to note here:

  • I have two organizations: ISV1 and SMB1 per the above discussion.
  • Both have a catalog. The SMB1-Cat catalog is private to the SMB1 organization. The ISV1-Cat is published to SMB1 (and all the other orgs on the cloud for that matter).
  • ISV1 only has one Org vDC. SMB1 has a more articulated Org vDC layout. Consider that SMB1 also has real workloads in the "My Cloud" whereas ISV1 mostly uses the Org vDC as a storage bucket to host catalog items.
  • I have scattered all the catalog items across the vDCs in SMB1 just to try to cover most of the deployment scenarios. This is far from being a best practice but it helps when trying to find out limitations and black-spots (which was the idea at the basis for these tests).

This is how the various catalog items are scattered in the ISV1-Cat catalog:

  • CentOS install media (Bronze Org vDC)
  • CentOS installed vApp (Bronze Org vDC)

This is how the various catalog items are scattered in the SMB1-Cat catalog:

  • Windows 7 installed vApp (Bronze Org vDC)
  • M0n0wall installed vApp (Silver Org vDC)
  • Windows 7 install media (Gold Org vDC)
  • M0n0wall install media (Gold Org vDC)
  • DSL install media (Gold Org vDC)

(M0n0wall and DSL are two small specialized Linux distros. I used them just to avoid lenghty big ISO manipulations and transfers). Let's now dig a bit deeper in the two use cases mentioned above.

Use case #1: ISVs to publish installed vApps for end-user consumption

This is pretty straightforward. You just need to make sure that the catalog is published (you can either do it at catalog creation time or opening its properties later on). This is something an Org admin has rights to do.

There is only one gotcha about this. I was expecting the two built-in groups vApp Author and vApp Users to have the right for accessing remote catalogs. This is not the case so, by default, these two user roles cannot deploy vApps from published catalogs (in other words catalogs external to their own organization). This is a right that, by default, has been assiciated to the Organization Administrator role only. If the Org admin needs users to have (also) access to external catalogs he needs to contact the cloud administrator to create custom roles and include that checkbox in the new role.

There is another thing to keep in mind though. This is not related to ISV1 being able to publish catalog to other orgs (the use case I wanted to discuss) but it's more of a configuration check for standard internal catalog consumption. The owner of the catalog needs to Share the catalog with users (in the same organization) explicitly allowing them to have access to it. For the sake of time, as the owner of the SMB1-Cat catalog, I have just given everyone in the SMB1 organization read-only access. If needed, access can be granted on a user per user basis in a very granular way.

All we have discussed here is independent from the Org vDC the vApp template has been saved on. A published (external) vApp or a shared (internal) vApp can be deployed on any available Org vDC regardless of the sorurce vApp template Org vDC. We will see this is not the case for media templates.

Use case #2: End-users to install their own Operating Systems from scratch

With this scenario we are taking a totally different approach. In the previous use case we wanted end-users to check-out a pre-built vApp from a catalog external to the organization (we have also touched briefly on consuming a catalog internal to the organization). In this use case we want end-users to be able to install their OS from scratch.

First of all we need to make sure the end-user has enough rights to create a VM in a vApp. For example the vApp Author role has these rights. The vApp User role doesn't as this role can only instantiate existing vApps from the local catalog.

While there may be a number of methods to install an OS I will just assume here that the installation needs to be done manually mapping an ISO image to the VM. At least this is the use case some service providers are coming back to us with. With this in mind there are three macro scenarios one could think of:

  • Service provider provided ISOs (from a published catalog)
  • Organization provided ISOs (from a local catalog)
  • End-user provided ISOs (from the end-user access device)

Let's start with the first one because it's easy. vCloud Director 1.0 does not allow making ISO templates available outside of the organization. This means that the service provider cannot create an organization with a published catalog for the purprose of making available ISOs to other tenants (aka organizations). This scenario only works, today, for vApp templates as we have seen in the previous use case.

The second scenario is a bit more complex. The short story is that, provided you have enough rights to do so, you can create a catalog local to the organization and share the media templates with internal users. In this case the internal users can create their own vApps and VMs and install an Operating System from scratch using the ISO images available from the local catalog. There is a caveat though that applies to media templates (and again doesn't apply to vApp templates): if you are deploying a vApp/VM in a certain Org vDC, only ISO files in the catalog that have been saved on that Org vDC can be mapped.

Let's try it out. I want to create a Test vApp that only has a brand new TestVM virtual machine in it. I am creating this vApp in the Silver Org vDC (called Silver-to-SMB1). Note I am logged in as user smb1 that has the vApp Author role associated (if that was a vApp User he/she wouldn't be able to create a VM from scratch). Once I have done that, I'll switch to the VM view and I'll try to insert a CD image into the VM I have just created.

When you do that vCloud Director tells you that there are indeed ISO images available in the catalog but that they are in a different Org vDC. In fact the TestVM is in the Silver Org vDC whereas all the ISO images I have imported into the SMB1-Cat are in the Gold Org vDC. vCD suggests you to either copy or move the ISO(s) you need to the Silver Org vDC to be able to use them.

Note the smb1 user cannot do that as he/she doesn't have enough privileges. This needs to be done by someone that have catalog manipulation rights (typically the Organization Administrator or the Catalog Author). After all we are still in the "Organization Provided ISO" scenario so it makes sense it's someone responsible for maintaining the organization (and its catalog) to do this.

At this point a person in the Org with sufficient authority can either copy or move the ISO(s) in the Silver Provider vDC. Note that moving them solve the problem for the VMs deployed in the Silver Org vDC but opens it up for VMs deployed in the Gold Org vDC. Copying them across all Orgs solves this although it may increase costs due to additional storage usage and operational requirements. This is something that needs to be taken into account in the planning phase.

Below I am showing how, as an Org admin, I can copy (in this case I decided to copy, not to move) one of the Linux ISOs from the Gold Org vDC to the Silver Org vDC:

If you try, as user smb1, to insert again an ISO into the TestVM above you'll notice that now you have an option to insert the M0n0wall-Silver ISO.

The third and last scenario I'd like to cover is the "End-user provided ISO". I have deleted the ISO I have just copied to the Silver Org vDC so I really have no technical option, in the TestVM created above, to use any "Organization Provided ISO". If you power up the Test vApp and you look at the remote console of the TestVM virtual machine you'd get this (no surprise):

The end-user can however connect a remote ISO instance by reconfiguring the appropriate Devices as shown in the picture below:

I have, in this case, connected the DSL ISO image that I still had on my laptop file system and I was able to boot off the VM using this image as shown:

This was just an example on how to initiate a remote OS install. I haven't ended up actually installing DSL into the VM as this was just to demonstrate the kick-off of an OS setup. Consider that while my boot user experience has been very good, DSL (Damn Small Linux) is a 50MB image. Booting a larger image may require more time.

The other thing to note is this is just one of the multiple ways to get "your" VM into the cloud. We have explored how to setup a VM from scratch using an ISO image (either available in the cloud or locally on the end-user device). Some cloud end-users may find easier to install the OS on a local VMware infrastructure (such as VMware vSphere or VMware Workstation), export it in OVF format and upload the vApp into the cloud. This can either be done through the vCD portal I have shown or through the vCloud APIs.

Conclusions

In conclusion, I wanted to share with you a few notes from the field on how to use the vCloud Director Catalog. Please keep in mind that this is not to be intended as official VMware documentation, recommendations or best practices. This was really an informal lab experiment. I commit to come back and fix some of my findings if I find them misleading as I continue to play with the technology. In the meanwhile please let me know what you think and what you may want to see different in the catalog behavior.

Massimo.