Shows you how to leverage the power of vDC's in UCSD to offer end-users a way to request VM deletion, but have
the system hold onto their VM's for a period of time before actually automatically removing them. VMs that are in "purgatory"
can still be accessible, and can still have a unique cost model associated to the business for showback / chargeback.
Tested on 5.x and 6.x (2 versions attached)
Workflow / Configuration
Instructions for Regular Workflow Use:
Download the attached .ZIP file below to your computer. *Remember the location of the saved file on your computer.
Unzip the file on your computer. Should end up with a .WFD file.
Log in to UCS Director as a user that has "system-admin" privileges.
Navigate to "Policies-->Orchestration" and click on "Import".
Click "Browse" and navigate to the location on your computer where the .WFD file resides. Choose the .WFD file and click "Open".
Click "Upload" and then "OK" once the file upload is completed. Then click "Next".
Click the "Select" button next to "Import Workflows". Click the "Check All" button to check all check boxes and then the "Select" button.
A new folder should appear in "Policies-->Orchestration" that contains the imported workflow. You will now need to update the included tasks with information about the specific environment.
Follow all configuration steps listed below.
One use case we often get is "Can my end users recover their VMs after they are deleted? One elegant, policy-driven solution to this is to leverage the power of UCSD's vDCs and policies!
This "VM Purgatory" solution allows an end-user to "Mark" one of their VMs for deletion. When selected, UCSD will automatically power off their VM, and move it from its current vDC to a "Purgatory vDC" - where it will sit for a configurable amount of time until it is actually automatically deleted. The end-user will get notified a pre-determined number of times before the VM is actually permanently deleted (could be days, weeks, even months later), and given an opportunity to recover the VM by moving it from the "Purgatory vDC" and back into its original vDC. Using the "vDC Locking" feature in UCSD, users are not able to actually provision VM's into the vDC by accident. The purgatory vDC can also have its own cost model if desired, so the cost of the VMs provisioned disk, for example, can still be charged back to the business. See the instructions below on how to configure this in your own UCSD environment:
First -- make sure that deletion of inactive VM's is actually enabled in your UCSD environment! Go to "Administration --> System --> Advanced Controls" and scroll all the way to the bottom. Make sure the following is selected:
Then follow these steps to enable VM Deletion using vDC Policy:
1. Pick an existing vDC in your environment that you want to enable this "VM purgatory" feature on. In my lab, we will use my "Development vDC". The first thing you are going to want to do is edit your vDC's existing "end user self service policy" so that users can no longer delete one of their VMs in the traditional sense: Policies --> Virtual/Hypervisor Policies --> Service Delivery --> End User Self Service Policy". Uncheck "VM Deletion Management"
2. Download and unzip the attached zip file, and go to "policies --> orchestration" and import the vm_purgatory.wfdx file:
3. Next, we need to create two new User VM Action Policies. Click on the "User VM Action Policy" tab (Policies --> Orchestration). The first policy we will create is for your existing vDC. If your vDC already has an action policy, edit it, increment the number of actions by one, and add the "Mark VM for Deletion" workflow to it. If your vDC does not have an existing action policy, click "Add" to create a new policy. Name it "vDC Action Policy" or something similar and set the number of actions to 1:
Click NEXT and configure the action as below:
Click SUBMIT and then select "ADD" to create a second action policy for your purgatory VDC. Configure as below:
4. Now we need to create a new "end user self service policy" for our Purgatory vDC to make sure that end-users can't do anything BUT unmark their VMs for deletion. Click on "Policies --> Virtual/Hypervisor Policies --> Service Requests --> End User Self Service Policy". Click ADD and name it "Purgatory vDC" or something similar. Make sure nothing is checked:
5. OPTIONAL STEP: Create a new cost model for the Purgatory vDC. One of the cool things about this method is that if you are using showback/chargeback, you can create a separate cost model to be applied to VMs that are marked for deletion. A common function is to continue charging for storage while the VM is waiting to be deleted. If you'd like to do this, click on "Policies --> Virtual/Hypervisor Policies --> Service Requests --> Cost Model" and select ADD. Create your cost model for your Purgatory vDC. I created mine to charge .05 cents per hour per GB of storage while VMs are waiting to be deleted:
6. You need to create a VM Management Policy for your Purgatory vDC. This is the policy that will govern how long VMs are kept before they are actually permanently deleted, as well as the notification rules for your end users. Click on "Policies --> Virtual/Hypervisor Policies --> Service Requests --> VM Management Policy" and click ADD to create a new policy. Make sure you uncheck "Configure VM Lease Notification" and fill out the rest similar to the screenshot below. I set mine to delete VMs after 7 days, and notify twice with 2 days remaining before deletion:
7. We are now ready to create our Purgatory vDC! Click on "Policies --> Virtual/Hypervisor Policies --> Virtual Data Centers". Select the vDC you want to enable this feature for, and select "Clone". In my example, I cloned my Development vDC. Name the new vDC to "Purgatory vDC", and be sure to click the vDC Locked button!!! This will not allow end users to actually provision new VMs to this vDC:
Scroll down to the "Policies" section and set the appropriate policies as below. Click ADD to save your new Purgatory vDC:
8. You need to edit the vDC that you want to enable this feature for (in my example, my Development vDC), and make sure it is pointing to the correct User Action Policy (If your vDC already had a User Action Policy assigned this should be done already. If you created a new User Action Policy for your vDC in step 3 you need to make sure you remember to do this step)!!! Edit the vDC that you want to enable this feature for, scroll down to policies, and make sure your User Action Policy is set:
9. Almost there! Last step! We need to set the "Mark VM For Deletion" workflow to move the selected VM to the newly created Purgatory vDC when it is run! Go to "Policies --> Orchestration" and open the workflow folder where you imported your workflows in Step 2. You will probably notice that one of the workflows called "Mark VM for Deletion" has a validation status of "failed":
Click on this workflow and select "Validate". Click on the edit pencil:
Click "Next" twice to get to the "Task Inputs" page. Select your Purgatory vDC:
That's it! You're done! Now users that can provision to that vDC will have the option to "Mark their VMs for Deletion". Try it out!
Log in to your end user portal as a service-end user. The first thing you will notice is that when you try to order a new VM, the "Purgatory vDC" will not show up in the user's drop down because the vDC is locked:
^^^^^^^^ Only my development vDC shows up when I try to order a new VM.
When an end-user clicks on a VM that they previously provisioned under "Virtual Resources --> VM", our new "Mark for Deletion" button shows up:
When "Mark VM for Deletion" is submitted for the selected VM, the VM will be shutdown and automatically moved into the "Purgatory vDC", where the VM Management Policy will be inherited. In my example, if no action is taken I will be notified two days before my VM is actually deleted. If I take no action, it will be rolled back and permanently deleted. Here is an example email:
When an end-user looks at his or her VMs in "Virtual Resources --> VMs" they can still see the VMs that have been marked for deletion in the Purgatory vDC. When they click on one, the only thing that they are able to do is select the "Unmark VM for Deletion" option, which would move the VM from the Purgatory vDC back into a valid vDC, thus preventing it from being wiped out by the VM Management Policy.
Hola a todos, solicite su ayuda, si alguien tiene conocimiento en como puedo implementar dentro del simulador de UCS un servidor físico y así mismo generar la conexión con los dos interruptores, ya que es mi primera vez manejando esta consola y...
Hello *, for our Server Teams I have to provide the information how the network configuration for the server (connected to cisco aci fabric) looks like.My first idea was at first to create an workflow to collect the information from the fabric ...
Hi, I am looking for a function, that takes a Service Request ID as input and returns the error messages from this (failed) workflow. I found this Workflow, which is almost as I needed: https://community.cisco.com/t5/ucs-director-documents/...
Dear experts, in one of my workflow, i am am running two powershell scripts and both are connected to following "Parse PowerShell Output" Task. first Task parse the Output correctly and result into 4 variables but second Task Show no variable. b...
Dear Experts,is it possible to read value of a Input in another Input. here is the Scenario. in a subworkflow I have two Tasks to be executed. I have defined two Input at workflow Level.InputfortaskA = <emailid> (this will be feeded by main wor...