LESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/typography.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/template.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/responsive.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/k2.less

Follow Me Icons

 

Follow @KendrickColeman on TwitterConnect on LinkedInWatch My Videos on YouTubeFollow me on FacebookCheck Out My Projects on GitHubStay Up To Date with RSS

Search

BSA 728x90 Center Banner

Understanding Lease Times in vCloud Director

I was with a customer the other day and and they asked me to go more in-depth with lease times. To be honest, my initial thought process was incorrect and I want to dive a bit more in-depth on some configurations. This will hopefully make you understand how lease times work with vCloud Director.

 

As a cloud admin, it's always a recommended practice to create an organization that aligns with something for your internal IT/Administrators. Having an internal org is necessary because you only want a select few organizations actually creating public catalogs for consumption across the vCloud. For instance, in my very own vCloud instance, I created an organization called KendrickColeman that gives me the ability to publish public catalogs. You wouldn't want tenants of the vCloud publishing vApps to other tenants.

 

 

 

Now, you're probably wondering, what does that have to with lease times? Well if you aren't careful, the organization that you created to be the host of the public catalog can have its own templates expire. For instance my IT Organization, KendrickColeman, creates the catalog that makes VMs such as Windows XP, Windows 2008R2 and UbuntuLite available across the vCloud.

 

By default, when you create an organization the maximum storage lease for a vApp template is 90 days. As soon as you import a vApp template into a catalog, the clock starts.

 

Once you hit that 90th day, this vApp will be unavailable because it has moved to one of two places chosen in the Storage Cleanup options. Of course, if you are a good IT admin, you will be updating your VMs in the catalog regularly because of patch cycles.

 

The easiest way to fix this problem is setting the vApp template lease to "Never Expires" when you are configuring an Organization. This also configurable after an organization has been created. As a primary public catalog publisher, now organizations will not be submitting help tickets because a vApp they used to access is no longer available. NOTE: this is ONLY for the IT or Admin Organization. You do not want to change this setting for every organization because we still will want other tenants catalogs to expire so we can reclaim that storage.

 

Now lets examine the leases and how they actually work. When we created an organization, there are some defaults that come into play, but these are configurable. As we can see from the drop down menu, you can completely customize the MAXIMUM amount of days or hours you want to set on a lease for that particular organization. This will all depend on your tenant because they may all have different requirements. Another thing to keep in mind is that the more and more VMs you have running, the more resources that are being consumed. Use lease times in your favor to make sure VMs aren't being dormant and are utilizing precious CPU and RAM.

 

We will just say you gave an organization the defaults for lease times. When it comes time for an organization to deploy their first vApp, they have the ability to reconfigure a vApp up to the maximum you defined, as the cloud admin, in the previous screenshot.

 

As soon as the vApp owner presses FINISH on creating a VM, the countdown timer for the Maximum Storage Lease begins. You don't even have to power on the vApp, the timer starts for how long this VM will actually be kept around to be powered on. Yet, once a vApp is powered on, the Maximum Runtime Lease begins and the Maximum Storage Lease is reset. After the Maximum Storage Lease expires, there are two actions that can take place, which are called Storage Cleanup options. The first is to "Move to Expired Items" which is a menu item under the My Cloud tab. The second option is to Permanently Delete the vApp.  The "Move to Expired Items" option will keep the vApp around indefinitely. It's very easy to restore an expired vApp by right clicking on the expired vApp and clicking to renew the lease. The lease renewal will not change from the original lease options given to it. The latter option, Permanently Delete, will not keep the vApps and will delete them from storage immediately. If you set the Storage Cleanup option to Move to Expired Items, you as the cloud admin, must keep a watchful on eye on expired items to make sure it doesn't start overtaking all your storage. Feature request if anyone from VMware is reading... Add a Permanently Delete after X days in Expired Items option to the lease times.

 

Once a vApp owner powers on a vApp for the first time is when the clock starts for the Maximum Runtime Lease. The Maximum Runtime Lease is how long a vApp can be powered on before its automatically suspended. It doesn't matter if you are working on the virtual machine because it doesn't take into account an idle period. This measure is put into place to keep dormant VMs from consuming CPU and RAM when it isn't necessarily being used. If you are on a Pay-as-you-go (PAYG) model with chargeback involved, perhaps you will want to set the runtime lease of a VM to 8 hours or during the working day when you know you are going to be using that VM. You can come in every morning, power on your VM, and you won't be charged for those nightly hours when your VM was turned on but wasn't being used. It's just like keeping the lights on in a room when no one is in there. As a cloud admin, be mindful of how much time you are allowing tenants to keep VMs powered ON so you aren't wasting resources.

 

In essence, a vApp could never die off. Sure, the Maximum Runtime Lease may expire, but as soon as you power it back on, the timer starts over and the Maximum Storage Lease timer is erased. As soon as the vApp powers off, the Maximum Storage Lease timer begins. It's a consistent cycle of power On and Off in relation to the timers associated.

 

If a vApp Owner originally created a vApp and set the lease times to 1 day for everything, it can be reset or reconfigured. Go over to My Cloud -> vApps -> Right Click on your vApp and click on properties.

 

The first page that comes up shows the lease times. From here you can do two things. You can hit check the Reset Leases check box which will restart the countdown timer for the vApp. Another option is once you reset the lease, you can change the amount of lease times available to your org depending on how long you want to keep this VM around.

 

**UPDATE** 12/21/2012 @ 10:07PM

Thanks to Josh for his comment below. I performed two more tests to see what the correlation is between the runtime and storage lease. I created 2 vApps, Both with a Runtime Lease of 1 Day and Storage Lease of 1 Hour. I kept 1 vApp turned off, and I turned another vApp on. The vApp that was kept off, moved to the expired items folder after 1 hour. The vApp that was powered on, however, was still on and didn't move to the expired folders. So I'm guessing that the moral of the story here is that you should always focus on the Runtime Lease first and then the Storage Lease to follow. A Storage Lease timer will only take effect if the vApp is powered OFF. Consider the Storage Lease more like "house keeping" and the Runtime Lease as "administrative know-how".

Related Items

Related Tags

LESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/styles/blue.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/styles/green.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/styles/orange.lessLESS ERROR : load error: failed to find /home4/kacole2/public_html/templates/tx_zenith/less/styles/purple.less