VMware Cloud Community
thomps01
Enthusiast
Enthusiast

vApp Templates - Datastore location

Is there any way within vCloud Director to specify that all vApp templates are located on particular datastores?

I have a single provider vDC containing 8 datastores and my organisation vDC's take storage from here.


I want to have a single catalog for all organisations and I've noticed that when I create new vApp templates, they are randomly placed across all 8 datastores.

In a vSphere only environment I'd usually have a LUN set aside specifically for templates which makes administration slightly easier and it feels like the correct thing to do.

As I only have a single DRS cluster available to create a provided VDC I don't see how else I can avoid this situation.


What do other people do?

0 Kudos
2 Replies
thomps01
Enthusiast
Enthusiast

I'm going to answer my own question here in the hope it might help someone else in the future.

Basically the only way within vCD 1.5 to control where the vApp templates are located is to create a new Provder vDC which only contains storage you wish to use for this purpose.

In my case I have an administrative organisation which is used to create a central catalog and publish this to all other orgs. For this I would present an org vDC created from the dedicated pVDC containing the storage for templates.

Now - If you're using vCloud Director 5.1 the problem / feature has changed for the better.

You can now have different classes of storage presented to the same org vCD.

Create a storage cluster in vSphere and include the LUNs you wish to use for vApp templates and ISO media.

Create a storage profile

Add the storage profile to the provider vDC and the org vDC being used for publishing the catalogs

That should do the trick.

0 Kudos
cfor
Expert
Expert

Looks like you have found the answer...  We have the same issue -

A couple items to note; if you have a system you would like to scale pretty large (we have > 20k VM's) - you may want to make your catalog VDC set to not used FastProvision - this can be a pain in copy times; but it makes sure your catalog content never ends up with a chain length > 1 - if this was to happen and you needed to deploy this content to a second vcenter (needed as you scale); this copy operation would have to use the ExportOVF operation.  And that operation can be very slow vs the normal copy file path that can be used if the the base catalog item is not chained from.

ChrisF (VCP4, VCP5, VCP-Cloud) - If you find this or any other answer useful please consider awarding points by marking the answer correct or helpful
0 Kudos