Managing the Service Lifecycle with the Expiry Policy

The Expiry policy allows you to identify and control services based on an expiry date, allowing you to ensure that you're not paying for unused services. For example, you can automatically suspend expired services.

For general information, see Managing Service Expiry.

The steps in setting up the Expiry Policy are:

1.Set expiry dates for existing services.

2.Create expiry groups if you choose not to use the Default Expiry Group.

NotePencil-smallIf you do not define your own expiry group, the Expiry policy automatically applies to the default group that contains all services.

3.Assign existing services to the expiry groups.

4.Configure the Default Attributes policy to add new services to expiry groups.

5.Configure the Expiry policy to trigger the appropriate actions on the services in the expiry groups.

6.Configure who receives email alerts about service expiry.

NotePencil-smallYou can also set expiry information with a workflow step. To ensure that the proper values are set, it's best practice to set metadata through policy or through a completion workflow, not both. The metadata values that are applied last are those that take effect.

How does the Expiry policy affect templates?

The Expiry policy changes the expiry state for templates, but policy actions (for example, deletion) are not performed for templates.

Best practice: Create an expiry group for templates and ensure that the expiry group is not affected by the Expiry Policy. In this way, when you convert a template to a VM to apply a patch, for example, the VM will not be deleted by the expiry policy.

caution

If you attempt to deploy a VM from a template in the Expired state, the deployment will fail.

Set expiry dates for services

Access through:

Views menu > Operational, VMs and Templates, or Datastore

Available to:

Administrator and All Operator Levels of Access Rights

To set the expiry date for a service:

1.Select a service from the tree, or select one or more services from a Virtual Machines tab.

2.Right-click, and choose Lifecycle Management (or Policy Enforcement) > Set Expiry Date.

NotePencil-smallTo set the expiry date for a virtual service, select a virtual service from the tree, right-click and select Set Expiry Date.

3.In the Set Expiry Date dialog, configure a date, and click OK.

Create expiry groups

Access through:

Configuration menu > Groups > Expiry

Available to:

vCommander Role of Superuser and Enterprise Admin

Administrator Access Rights

All services are automatically a member of the Default Expiry Group until you reassign them. You can change the name of the default group but you cannot delete it.

To create an expiry group:

1.On the Expiry Groups page, click Add.

2.In the Add Group dialog, enter a name for the expiry group (maximum 100 characters).

NotePencil-smallGive the group a descriptive name so that it makes sense to service owners viewing the service's Expiry Group property, and so that administrators can easily set the proper group when required.

3.In the Description field, enter details about the expiry group.

4.Click OK.

Add existing services to expiry groups

Access through:

Views menu > Operational, VMs and Templates, or Datastore

Available to:

Administrator and All Operator Levels of Access Rights

In vCommander, services are automatically assigned to a default expiry group. You can easily add one or more services to your own predefined expiry group.

NotePencil-smallExpiry groups apply to all service types — VMs, virtual services, stacks, databases, load balancers, and auto scaling groups.

If you move a service from one infrastructure element to another, any group name and any expiry information you assigned to that service remains with it, so check the service and make any changes that are appropriate.

NotePencil-smallWe recommend that all VMs in a virtual service belong to the same expiry group.

To add a service to an expiry group:

1.Navigate to and select the service either through the tree or the Virtual Machines tab.

2.Right-click and select Lifecycle Management (or Policy Enforcement) > Set Expiry Group.

3.From the list of group names, select the appropriate group and click OK.

The group name is displayed on the Operational pane of the Summary tab.

Add new services to expiry groups

Access through:

Configuration menu > Policies

Available to:

vCommander Role of Superuser and Enterprise Admin

Administrator Access Rights

You can automatically set an expiry group for new services by configuring the Default Attributes policy. To learn how to configure the Default Attributes policy, see Assigning Groups to Services with the Default Attributes Policy.

Configure the Expiry Policy

Access through:

Configuration menu > Policies

Available to:

vCommander Role of Superuser and Enterprise Admin

Administrator Access Rights

To configure the Expiry policy:

1.On the Policies tab, click Add.

2.On the Choose a Policy page, select Expiry from the list of policies.

3.On the Policy Name/Description page, enter a name, for example, Expiry Policy for Production (maximum 100 characters), and an optional description.

4.On the Choose a Target page, select the expiry group from the list of group names. If you want the policy to run on all services that have not been assigned to a specific expiry group, select the Default Expiry Group.

5.Expand the Operational tree if required and select the infrastructure element to which you want to apply the Expiry policy.

If an infrastructure element has already been configured with the policy, then it is no longer available for this particular instance. You can only apply one instance of the same policy to the same infrastructure element.

NotePencil-smallYou cannot select a folder as a target.

7.On the Configure the Policy page, to enable the policy as soon as you have completed this wizard, make sure Enabled is checked.

8.Specify actions to take place before, on, or after the expiry date, and specify how long before the expiry date, or how long after the expiry date, these actions should occur.

9.From each of the Take Action drop-down menus, select from the options. Note that not all actions are valid for all service types.

Option:

Result:

Quarantine

The VM is quarantined.

Note: If you include this action in a policy targeting services in a managed system other than vCenter, the action will fail.

Suspend

The VM is suspended (saved in its current state).

Not supported for VMs in public cloud managed systems. If you include this action in a policy targeting services in a public cloud managed system, the action will fail.

Stop

The Guest OS is shut down. You can set the service to stop on all three instances. However, the first instance that you choose is the one on which the service stops.

Remove from Inventory

The VM is removed from inventory. Note that the file remains in the datastore.

When all VMs are deleted from a virtual service through a policy action (that is, when VMs are deleted by a policy action or by a command workflow attached to an expiry policy), the empty virtual service is not automatically deleted unless it too is targeted by policy.

Note: If you include this action in a policy targeting services in a managed system other than vCenter, the action will fail.

Set State as EOL

The End of Life flag for the VM and its associated files is set to True. If an End of Life Policy is enabled for the VM, the End of Life policy will be triggered. Affects only VMs and virtual services.

Delete from Disk

The service and its associated files are deleted permanently from disk. No other options can be carried out on this service after it is deleted.

When you delete a VM or template from the disk, the files are permanently deleted. They cannot be recovered unless you have a backup copy.

When all VMs are deleted from a virtual service through a policy action (that is, when VMs are deleted by a policy action or by a command workflow attached to an expiry policy), the empty virtual service is not automatically deleted unless it too is targeted by policy.

Run [Workflow]

Existing command workflows appear for selection, organized by target type. If the policy is triggered, the selected workflow is run.

NotePencil-smallYou must choose a workflow with a target type that matches the target of the policy; otherwise, the workflow will fail. For example, if the selected workflow's target type is "VM", the workflow will fail if the policy targets a database. A workflow with a target type of All Types can be run on all service types.

Click Add Workflow to set up a new command workflow.

10.Specify a number of days before the expiry date (default: 7) and after the expiry date (default: 30) when the selected action will be triggered.

NotePencil-smallA service has the Expired state between the expiry date and the last trigger date you configure. A service has the Post Expiry state if it continues to exist after the last trigger date. For example, if you keep the default setting of 30 days after the expiry date, a service that continues to exist after 30 days has the Post Expiry state.

11.On the Expiry Extension page, you can allow primary owners to extend the expiry date of a service.

When you enable this feature, if a service has a primary owner with an email address, the expiry email that the primary owner receives will contain an Extend Expiry Date section, with a link:

expiry-extension-email

As soon as the user clicks the link in the email, the expiry date is automatically extended by the number of days you specify in this step:

expiry_extension

NotePencil-smallAnother way to allow service expiry extension is through a change request. If you add the Expiry Date element to the Service Change Request form, users can submit a change request to extend the expiry date. The benefit of change requests is that you can configure an approval process.

When you enable expiry extension:

Specify the number of days that the expiry date will be extended. The default is 90.

Specify the maximum number of extensions that the user is allowed. If you do not specify a value, the user will be able to extend the expiry date an unlimited number of times. The default is unlimited.

If you want to change the service's approval state when the expiry date is extended, select Set to unapproved from the Approval state will be drop-down menu. By default, the approval state will be Unchanged.

NotePencil-smallYou can view and reset the number of expiry extensions remaining for a service. See Managing Service Expiry.

11.On the Notifications page:

a)Select the owners to whom notification emails should be sent when the Expiry policy is triggered.

NotePencil-smallOwners receive emails about the expiry policy only if their email address has been configured. For more information about setting up owners, see Assigning Ownership to Services.

bestpract-checkmark2

Configure service owners to receive expiry alerts by email for their services.

b)Customize the email subject and body.

NotePencil-smallClicking vars-20x20 in any text field that supports variables opens the Variable Assistant, which allows you to select variables for the current context and provides help for each variable.

12.On the Summary page, if you have enabled the policy and as a result, any services will be immediately affected by it, vCommander displays the number of affected services.

To see what services are affected by the policy actions you selected, click Review, then click OK to return to the summary.

14.Click Finish to complete the configuration.

Deleting expiry groups

Access through:

Configuration menu > Groups > Expiry

Available to:

Administrator Access Rights

To delete an expiry group, select the expiry group you want to delete, click Delete, and confirm the deletion.

caution

When you delete an expiry group, all services in the group are automatically reassigned to the Default Expiry group. Any policy actions that are set for the default group affect the services in that group.

Before deleting, check to see what policy actions you have assigned to that group.