top of page

Experienced Technology Product Manager adept at steering success throughout the entire product lifecycle, from conceptualization to market delivery. Proficient in market analysis, strategic planning, and effective team leadership, utilizing data-driven approaches for ongoing enhancements.

  • Twitter
  • LinkedIn
White Background

"Change Lease" for Multiple Deployments

Updated: Jun 9, 2022

A Machine blueprint is a standalone blueprint that other architects can reuse as a component in application blueprints, and catalog administrators can include in catalog services.


You can specify settings that apply to the entire blueprint by using the Blueprint Properties page when you create the blueprint. After you create the blueprint, you can edit these settings on the Blueprint Properties page.


Settings on the General tab apply to the overall blueprint.

Lease (days) Minimum and Maximum

Enter a minimum and maximum value to allow users to choose from within a range of lease lengths. When the lease ends, the deployment is either destroyed or archived. If you do not specify a minimum or maximum value, the lease is set to never expire.

Enter lease information for your machines in your vRealize Automation blueprint, not in the source endpoint application. If you specify lease information in an external application, that lease information is not recognized or used in vRealize Automation.


Archive days You can specify an archival period to temporarily retain deployments instead of destroying deployments as soon as their lease expires. Specify 0 to destroy the deployment when its lease expires. The archive period begins on the day the lease expires. When the archive period ends, the deployment is destroyed. The default is 0.

In my example above I've set the minimum to 40 days and Maximum to 80 days


Propagate updates to existing deployments

Broadened minimum-maximum ranges for CPU, memory, or storage are pushed to active deployments that were provisioned from the blueprint. The new range must fully encompass the old range. For example, for an original minimum 32 and maximum 128 (32, 128), a change such as (16, 128) or (32, 256) or (2, 1000) can take effect upon reconfiguration or scale-out, but a change of (33, 512) or (4, 64) cannot.

The changes take effect upon the next reconfigure or scale-out action


When I deploy VM's out of this blueprint it would set these values to them as you can see in the screenshot



As you can see the values for these deployments is set to expiring in 1 month


If there are a handful of virtual machines then changing lease period to "Never Expires" is pretty easy


Remove the values of Lease (days) under blueprint properties and set Archive (days) to 0

Once done, click on OK, then Save and Finish to close the blueprint pane.

This will ensure that all future deployments are set to "Never Expires" as soon as they are deployed.


How about existing deployment's then?

One can browse to Deployment's tab and then click on "Change Lease", a day 2 action and then set it to "Never Expires"



How to execute "Change Lease" is present in this short recording below.


What if you have hundreds of deployment's and you would like to change them in one go?


Practically heading to every deployment and changing lease manually is an impossible task.


The only way available to change lease on multiple deployments in one go is to modify vRA's Postgres database tables


So let's provision a few virtual machines where the lease is set and we will use queries to make changes to these deployment's to set lease to never expire



As you can see in the screenshot above, I've made changes to Lease (days) to start with 1 and to go up to 6 days.


I have three deployments in my lab to play around with. As you may see in the below screenshot lease expires in about a months time



Pre-Requisites before making any changes to Database


Let's now connect to vRA's Postgres database. You may use a shell session to connect or use the pgAdmin tool. Anything works.


Use below query to find out how many deployments we have to modify whose expiration date is in future


select name,status,leasestate,resourcetype_id,lease_end_date from cat_resource where 1=1
  and status = 'ACTIVE'
  and leasestate in ('ACTIVE','ACTIVE_REMINDER_SENT')
  and resourcetype_id = 'composition.resource.type.deployment'
  and lease_end_date is not null
  and lease_end_date > now();



Note: In my lab, since expiration is less than 24 hours, leasestate is set to ACTIVE_REMINDER_SENT , normally if the expiration is more than 24 hours it would be set to ACTIVE


Step#1

Begin a transaction


begin;



Step#2

Modify deployment records



-- Step 2 -- 
--DEPLOYMENT records --
update cat_resource
set lease_end_date = '2025-12-06 01:23:45.678' --temporary "flag" value...used in last update to identify correct Deployments --
where 1=1
  and status = 'ACTIVE'
  and leasestate in ('ACTIVE','ACTIVE_REMINDER_SENT')
  and resourcetype_id = 'composition.resource.type.deployment'
  and lease_end_date is not null
  and lease_end_date > now();  --Expiring in the future.


Step#3

You're modifying any dependent children or any of sub dependent records



--Step 3 --
--update ALL the VIRTUAL MACHINE children records of the above DEPLOYMENTS --
update cat_resource crvm
set lease_end_date = null
from (select id, lease_end_date
      from cat_resource
      where lease_end_date = '2025-12-06 01:23:45.678'
        and status = 'ACTIVE'
        and leasestate in ('ACTIVE','ACTIVE_REMINDER_SENT')
        and resourcetype_id = 'composition.resource.type.deployment'
     ) x
where crvm.parentresource_id = x.id;


Step#4

Updating software components if it exists



--Step 4 --
--update ALL the SOFTWARE COMPONENTS that are
--children of VIRTUAL MACHINE children records of the above DEPLOYMENTS --
update cat_resource crsw --software components of the VMs --
set lease_end_date = null
from (select id, lease_end_date
      from cat_resource
      where lease_end_date = '2025-12-06 01:23:45.678'
        and status = 'ACTIVE'
        and leasestate in ('ACTIVE','ACTIVE_REMINDER_SENT')
        and resourcetype_id = 'composition.resource.type.deployment'
     ) x
join cat_resource crvm
  on crvm.parentresource_id = x.id
where crsw.parentresource_id = crvm.id;
 

Step#5

Changing cat_resource table with a null value under lease_end_date to change expiration to "NEVER EXPIRES"



--Step 5 --
update cat_resource
set lease_end_date = null
where 1=1
  and status = 'ACTIVE'
  and leasestate in ('ACTIVE','ACTIVE_REMINDER_SENT')
  and resourcetype_id = 'composition.resource.type.deployment'
  and lease_end_date is not null
  and lease_end_date = '2025-12-06 01:23:45.678';  --very important to ensure only updating the correct Deployments.
 


If you're satisfied with the output and it matches the number of deployments then


commit; 

otherwise


rollback;





Step#6

If committed, then you would find the lease status of the VM's changed to "NEVER EXPIRES"





Happy Learning. As stated above before making any changes to database ensure appropriate backups are taken.



1,830 views0 comments

Recent Posts

See All

コメント

5つ星のうち0と評価されています。
まだ評価がありません

評価を追加
bottom of page