How to manually change deployment lease after maximum in vra 7.2?

[darrenoid]

Hello,

After upgrading to vra 7.2 the max lease date is now actually enforced, which is great. We were finding a lot of our end users where setting the lease to never expire! However, there are some circumstances where we may want to extend a lease beyond the maximum. As an administrator I should be able to do that even if the end user cannot. Does anyone know of a way to change leases beyond what the blueprint constraints are on a case by case basis?

Thanks,

Darrenoid

[SeanKohler]

Well... you won't get around it through normal request.  The error/constraint is on REST POST.

I would try to handle this requirement by having a Blueprint that has a much longer max lease time.  Reconfigure the machine (consumer resource) to that blueprint.  Extend the lease to within the new, much longer, maximum.

This Blueprint doesn't need to be entitled to the end user for the machine to be assigned to it post provision, however it will greatly depend on the methods you use with Resource Actions. In the worse case, you could just have the catalog item available for request, but put an approval policy on it to prevent your users from requesting it.

[SeanKohler]

Oh... and there was once a hack that allowed us to have a Blueprint (catalog item) in an entitlement, but have the catalog item itself disabled.  I suspect in this configuration, you could keep users from requesting the catalog item that has the LONG Max Lease... but they would still be able to run resource actions found in the entitlement if a machine item was moved to the Blueprint through reconfigure.

[darrenoid]

Well, I was mostly confused on this one. I was assuming the max lease date was a static date in time after which the VM would be expired with no way to extend the lease. It is actually max lease days, so the lease can be continually extended forever. Also the max lease days is just a maximum that the user can set during deployment. If min lease days is 1 and max lease days is 14, if the user chooses 8 during deployment, then the VM lease can only be extended for 8 days at a time.

I was still curious if there was any way to change the lease days value, so a VM that was deployed with a short lease time could be extended less often (convenience). I scoured the database and I found "__Cafe.Request.VM.LeaseDays" in the VirtualMachineProperties table in the IaaS database. Changing this value does not change the lease days for a VM. Also, if I change the max lease days on the blueprint itself, it does not change the max lease days on any previously provisioned machines. For the life of me I cannot find this value anywhere in the IaaS database or the appliance database. Where the heck is vRA checking the lease days when this error message is thrown?

The above error message is incorrect as well, the "latest expiration date" in my blueprint is 45 days (max lease days). The minimum is 1. When the VM was deployed the lease days was set to 17 days. Now 17 days is all it will allow me to extend.

Regards,

Darrenoid

[SeanKohler]

>> If min lease days is 1 and max lease days is 14, if the user chooses 8 during deployment, then the VM lease can only be extended for 8 days at a time.

That is a curious behavior.  I will look into this, too.  If I find something... will let you know.

[darrenoid]

Never mind, I was confused again. March 17th in the error message above is 45 days. Feb. 17 would have been 17 days. 45 days was the max lease days on the blueprint I was testing.

When a VM is deployed from a blueprint the max lease days is stored somewhere and that controls the maximum amount of days a lease can be extended for that VM. If the blueprint is changed to have a longer max lease days, it does not alter the amount of days the previously deployed VM can be extended. I cannot find where in the database this entry is stored...

~ Darrenoid

[SeanKohler]

I think changing it in the database will be the equivalent of changing it in the blueprint.  I do not think it is stored with the machine (as the relationship of custom properties, etc are).  It appears to me that the lease change looks up the value referenced in the blueprint record. 

Your option may only be to move the machine to another blueprint before change lease.  This capability doesn't exist in the GUI in 7.  I am not sure if they removed the capability entirely or not.

If it references the blueprint value (which I think it probably does), you can only find a solution by changing the blueprint it references. This is where I would look.

I would also first see if it can be done through API before modifying DB tables.

[Mr_Sanjay · Accepted solution]

I think you can use cloudclient to detach the VM and later import to a deployment of a different blueprint.

Removing a virtual machine from vRealize Automation 7.x using Cloud Client (2144269) | VMware KB

[raptorirl]

+1 for this request 🙂 ,

See this in vRA 7.1 too. Nice that the Change Lease is enforced,  Sean helped me before with working out how to enforce a restriction on the lease change in 6.2 🙂 , however this is now redundant in vRA 7.x

There are exceptions where we would wish that the Lease is extended beyond the blueprint Max, ( under admin control) , for a number of reasons. Without this capability it could easily lead to a bad customer experience.. ' I understand your need for the lease to be extended by 2 weeks, and would love to help , but can't - your VM will expire & get destroyed'.. is not a nice conversation with a customer... 🙂

Thanks,

     John,

[darrenoid]

Hey John,

I had the same reaction, but I realized that even with a 2 weeks lease max, the end user can extend the lease 2 weeks at a time, forever.

Un-registering and re-importing the VM attached to a new (or modified) blueprint does change the lease max.

Thanks everyone,

Darrenoid

[npadmani]

On vRA PostgresDB:

select * from cat_resource where name = '<Name of Deployment in UI>';

select * from cat_resource where name = '<Name of the VM in UI>';

---

update cat_resource set lease_end_date = NULL where name = '<Name of Deployment in UI>';

update cat_resource set lease_end_date = NULL where name = '<Name of the VM in UI>';

get back in UI and check Expiration date for the same.

I have tested this in vRA 7.1 test lab successfully, proceed with caution in production environment though.

if situation is too desperate and you don't want to go as far as re-importing deployment, this could be helpful.

[raptorirl]

Ahh I think I see what you're saying.

If I have a BP with a max Lease of 5 Days, and I provision a VM today.  with a 1 day lease..

Today I can extend it to Current Life= 0+5 days.

Tomorrow I can extend it  to Current Life= 1+5 days. ( or effectively 6 days from when it was created)

On day X , I can still extend it for a further 5 days. (so Life would be X + 5 )

ie the Change Lease will allow the lease to be extended by the max set in the blueprint, from today...

(will test this, if this is the case then it is a step up from the original 6.x Change lease, but we'll still need a wrapper around it for our users, so they can't extend beyond a fixed point, ( and then us as Admins , can still use the default change lease) 

[SeanKohler]

raptoriri... Your understanding on both accounts is correct...

1. Change lease is now a moving window from today.  (which makes a lot of sense, because if you can provision a new machine today for 30 days... most would think you could keep your existing machine for 30 more days)

2. If you want a hard stop on a machine, you have to write a change lease wrapper that takes original lease end date into effect.