Practice Free NCP-MCA Exam Online Questions
Question #1
What are the two Calm SaaS API Key components? (Choose two.)
- A . SaaS Token
- B . Token
- C . JSON file
- D . Name
Correct Answer: BD
BD
Explanation:
The Calm SaaS API key consists of two components: name and token. The name component is analogous to the ID or username you provide when you configure your Calm tunnel client VM to establish the tunnel connection. The token component is analogous to the password portion of the HTTP basic authentication. The Calm SaaS API key is used along with the Calm APIs and Calm DSL to access Calm. The API key file that you download will have the name and token components in the JSON format.
Reference: Nutanix Support & Insights
BD
Explanation:
The Calm SaaS API key consists of two components: name and token. The name component is analogous to the ID or username you provide when you configure your Calm tunnel client VM to establish the tunnel connection. The token component is analogous to the password portion of the HTTP basic authentication. The Calm SaaS API key is used along with the Calm APIs and Calm DSL to access Calm. The API key file that you download will have the name and token components in the JSON format.
Reference: Nutanix Support & Insights
Question #2
An administrator is configuring Playbooks and is concerned about adding or reducing CPU and
memory resources to VMs.
Which two prerequisites should an administrator take into consideration when configuring the Playbooks? (Choose two.)
- A . CPU can be added to a powered on VM if the guest OS supports it
- B . VM must be powered off to add CPU
- C . VM must be powered off to reduce memory
- D . Memory can be removed from a powered on VM if the guest OS supports it
Correct Answer: A, D
A, D
Explanation:
When configuring Playbooks to automate the scaling of CPU and memory resources for VMs, the administrator should consider the following prerequisites:
CPU can be added to a powered on VM if the guest OS supports it. This is also known as hot-plug CPU. The administrator should check the compatibility of the guest OS and the hypervisor before enabling this feature. For example, Windows Server 2019 supports hot-plug CPU on AHV, ESXi, and Hyper-V, but not on XenServer1.
Memory can be removed from a powered on VM if the guest OS supports it. This is also known as hot-unplug memory. The administrator should check the compatibility of the guest OS and the hypervisor before enabling this feature. For example, Linux supports hot-unplug memory on AHV, ESXi, and XenServer, but not on Hyper-V2.
VM must be powered off to add CPU if the guest OS does not support hot-plug CPU. This is also known as cold-plug CPU. The administrator should plan for the downtime required to power off and power on the VM after adding CPU.
VM must be powered off to reduce memory if the guest OS does not support hot-unplug memory. This is also known as cold-unplug memory. The administrator should plan for the downtime required to power off and power on the VM after reducing memory.
Reference: Nutanix Multicloud Automation Administration (NMCAA), page 10; Nutanix Certified Professional – Multicloud Automation (NCP-MCA), section 3; Nutanix Support Portal – Guest OS Compatibility Matrix
Reference: https://portal.nutanix.com/page/documents/details?targetId=Prism-Central-Guide-Prism-v6_0:mul-vm-prerequisites-playbook-actions-pc-r.html#vm-prerequisites-playbook-actions-pc-r
A, D
Explanation:
When configuring Playbooks to automate the scaling of CPU and memory resources for VMs, the administrator should consider the following prerequisites:
CPU can be added to a powered on VM if the guest OS supports it. This is also known as hot-plug CPU. The administrator should check the compatibility of the guest OS and the hypervisor before enabling this feature. For example, Windows Server 2019 supports hot-plug CPU on AHV, ESXi, and Hyper-V, but not on XenServer1.
Memory can be removed from a powered on VM if the guest OS supports it. This is also known as hot-unplug memory. The administrator should check the compatibility of the guest OS and the hypervisor before enabling this feature. For example, Linux supports hot-unplug memory on AHV, ESXi, and XenServer, but not on Hyper-V2.
VM must be powered off to add CPU if the guest OS does not support hot-plug CPU. This is also known as cold-plug CPU. The administrator should plan for the downtime required to power off and power on the VM after adding CPU.
VM must be powered off to reduce memory if the guest OS does not support hot-unplug memory. This is also known as cold-unplug memory. The administrator should plan for the downtime required to power off and power on the VM after reducing memory.
Reference: Nutanix Multicloud Automation Administration (NMCAA), page 10; Nutanix Certified Professional – Multicloud Automation (NCP-MCA), section 3; Nutanix Support Portal – Guest OS Compatibility Matrix
Reference: https://portal.nutanix.com/page/documents/details?targetId=Prism-Central-Guide-Prism-v6_0:mul-vm-prerequisites-playbook-actions-pc-r.html#vm-prerequisites-playbook-actions-pc-r
Question #3
Which option is used to test or validate scripts before deployment?
- A . Test Script
- B . EScript
- C . PowerShell
- D . Shell
Correct Answer: A
A
Explanation:
Test Script is a feature of Nutanix Cloud Manager (NCM) Self-Service that allows users to test or validate scripts before deployment. Test Script enables users to run scripts on a VM without creating a blueprint or a runbook. Users can select a VM, choose a script type, enter the script content, and execute the script. The output of the script is displayed in the Test Script window. Test Script can be used to troubleshoot errors, verify functionality, or preview the results of a script before using it in a blueprint or a runbook.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) Exam Blueprint Guide, page 14, section 3.1. Nutanix Multicloud Automation Administration (NMCAA) course, module 3, lesson 4. Validate Your Nutanix Cloud Manager Self-Service Skills + Access Special Offer.
A
Explanation:
Test Script is a feature of Nutanix Cloud Manager (NCM) Self-Service that allows users to test or validate scripts before deployment. Test Script enables users to run scripts on a VM without creating a blueprint or a runbook. Users can select a VM, choose a script type, enter the script content, and execute the script. The output of the script is displayed in the Test Script window. Test Script can be used to troubleshoot errors, verify functionality, or preview the results of a script before using it in a blueprint or a runbook.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) Exam Blueprint Guide, page 14, section 3.1. Nutanix Multicloud Automation Administration (NMCAA) course, module 3, lesson 4. Validate Your Nutanix Cloud Manager Self-Service Skills + Access Special Offer.
Question #4
An administrator has been asked to review and clean up all existing categories within the Nutanix environment.
What information should the administrator filter on to organize the findings and eliminate unused categories?
- A . Policies, Triggers, Categories, and Entities
- B . Blueprint, Triggers, Categories, and Polices
- C . Blueprint, Policies, Value, and Entities
- D . Name, Value, Entities, and Policies
Correct Answer: D
D
Explanation:
According to the Nutanix Prism Central Guide1, categories are key-value pairs that can be assigned to entities such as VMs, images, blueprints, etc. Categories can be used to filter, group, and manage entities based on their attributes. To review and clean up all existing categories within the Nutanix environment, the administrator should filter on the name, value, entities, and policies of the categories. The name and value of the categories identify the category type and the category value respectively. The entities show how many and which entities are assigned to the category. The policies show how many and which policies are associated with the category. By filtering on these information, the administrator can organize the findings and eliminate unused categories.
Reference: 1 Nutanix Prism Central Guide: Categories2
D
Explanation:
According to the Nutanix Prism Central Guide1, categories are key-value pairs that can be assigned to entities such as VMs, images, blueprints, etc. Categories can be used to filter, group, and manage entities based on their attributes. To review and clean up all existing categories within the Nutanix environment, the administrator should filter on the name, value, entities, and policies of the categories. The name and value of the categories identify the category type and the category value respectively. The entities show how many and which entities are assigned to the category. The policies show how many and which policies are associated with the category. By filtering on these information, the administrator can organize the findings and eliminate unused categories.
Reference: 1 Nutanix Prism Central Guide: Categories2
Question #5
An administrator wants to create two database VMS using replicas and needs to access the same mount_path for hosting the backup files during the deployment on both VMs.
What should the administrator do on the Blueprint to achieve this requirement?
- A . Set mount_path = u01/app/backup as a runtime variable
- B . Set mount_path = u01/app/backup as a runtime replica
- C . Set mount_path = u01/app/backup as a runtime task
- D . Set mount_path = u01/app/backup as a runtime service
Correct Answer: A
A
Explanation:
Runtime variables are used to pass information between different components of a Blueprint, such as VMs, services, tasks, and replicas. They can be defined in the Blueprint YAML file or in the UI. By setting the mount_path as a runtime variable, the administrator can ensure that both database VMs use the same value for the mount_path during the deployment. This way, the backup files can be hosted on the same location for both VMs.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) 6.5 Exam, page 25, section 2.1.1:
“Runtime Variables”
[Nutanix University: NCP-MCA 6.5 Exam Prep – Runtime Variables], video 2: “Runtime Variables”
A
Explanation:
Runtime variables are used to pass information between different components of a Blueprint, such as VMs, services, tasks, and replicas. They can be defined in the Blueprint YAML file or in the UI. By setting the mount_path as a runtime variable, the administrator can ensure that both database VMs use the same value for the mount_path during the deployment. This way, the backup files can be hosted on the same location for both VMs.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) 6.5 Exam, page 25, section 2.1.1:
“Runtime Variables”
[Nutanix University: NCP-MCA 6.5 Exam Prep – Runtime Variables], video 2: “Runtime Variables”
Question #6
What two pieces of information can an administrator obtain from Plays? (Choose two.)
- A . Host where the action runs
- B . Start time and end time of each action
- C . Execution result status
- D . CVM IP where the alert was triggered
Correct Answer: A, C
A, C
Explanation:
Plays are event-driven automation workflows that can be triggered by alerts, schedules, or manual actions. They consist of one or more actions that run on specified hosts or clusters.
An administrator can obtain the following information from Plays:
Host where the action runs: Each action in a Play can be configured to run on a specific host or cluster, or on the host or cluster where the alert was triggered. The administrator can view the host or cluster name for each action in the Play details page.
Execution result status: Each action in a Play has an execution result status that indicates whether the action was successful, failed, skipped, or cancelled. The administrator can view the status for each action in the Play details page, as well as the overall status of the Play.
The other options are incorrect because:
Start time and end time of each action: Plays do not show the start time and end time of each action, only the duration of the action. The administrator can view the duration for each action in the Play details page, as well as the overall duration of the Play.
CVM IP where the alert was triggered: Plays do not show the CVM IP where the alert was triggered, only the host or cluster name where the alert was triggered. The administrator can view the host or cluster name for the alert in the Play details page.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) Exam Blueprint Guide, Section 1.2
Nutanix Multicloud Automation Administration (NMCAA) Course, Module 4: X-Play
Training Spotlight: Nutanix Multicloud Automation Administration (NMCAA), Video 4: X-Play
Reference: https://portal.nutanix.com/page/documents/solutions/details?targetId=Nutanix_Hybrid_Cloud_Reference_Architecture:top-incorporating-optional-nutanix-products-and-services.html
A, C
Explanation:
Plays are event-driven automation workflows that can be triggered by alerts, schedules, or manual actions. They consist of one or more actions that run on specified hosts or clusters.
An administrator can obtain the following information from Plays:
Host where the action runs: Each action in a Play can be configured to run on a specific host or cluster, or on the host or cluster where the alert was triggered. The administrator can view the host or cluster name for each action in the Play details page.
Execution result status: Each action in a Play has an execution result status that indicates whether the action was successful, failed, skipped, or cancelled. The administrator can view the status for each action in the Play details page, as well as the overall status of the Play.
The other options are incorrect because:
Start time and end time of each action: Plays do not show the start time and end time of each action, only the duration of the action. The administrator can view the duration for each action in the Play details page, as well as the overall duration of the Play.
CVM IP where the alert was triggered: Plays do not show the CVM IP where the alert was triggered, only the host or cluster name where the alert was triggered. The administrator can view the host or cluster name for the alert in the Play details page.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) Exam Blueprint Guide, Section 1.2
Nutanix Multicloud Automation Administration (NMCAA) Course, Module 4: X-Play
Training Spotlight: Nutanix Multicloud Automation Administration (NMCAA), Video 4: X-Play
Reference: https://portal.nutanix.com/page/documents/solutions/details?targetId=Nutanix_Hybrid_Cloud_Reference_Architecture:top-incorporating-optional-nutanix-products-and-services.html
Question #6
What two pieces of information can an administrator obtain from Plays? (Choose two.)
- A . Host where the action runs
- B . Start time and end time of each action
- C . Execution result status
- D . CVM IP where the alert was triggered
Correct Answer: A, C
A, C
Explanation:
Plays are event-driven automation workflows that can be triggered by alerts, schedules, or manual actions. They consist of one or more actions that run on specified hosts or clusters.
An administrator can obtain the following information from Plays:
Host where the action runs: Each action in a Play can be configured to run on a specific host or cluster, or on the host or cluster where the alert was triggered. The administrator can view the host or cluster name for each action in the Play details page.
Execution result status: Each action in a Play has an execution result status that indicates whether the action was successful, failed, skipped, or cancelled. The administrator can view the status for each action in the Play details page, as well as the overall status of the Play.
The other options are incorrect because:
Start time and end time of each action: Plays do not show the start time and end time of each action, only the duration of the action. The administrator can view the duration for each action in the Play details page, as well as the overall duration of the Play.
CVM IP where the alert was triggered: Plays do not show the CVM IP where the alert was triggered, only the host or cluster name where the alert was triggered. The administrator can view the host or cluster name for the alert in the Play details page.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) Exam Blueprint Guide, Section 1.2
Nutanix Multicloud Automation Administration (NMCAA) Course, Module 4: X-Play
Training Spotlight: Nutanix Multicloud Automation Administration (NMCAA), Video 4: X-Play
Reference: https://portal.nutanix.com/page/documents/solutions/details?targetId=Nutanix_Hybrid_Cloud_Reference_Architecture:top-incorporating-optional-nutanix-products-and-services.html
A, C
Explanation:
Plays are event-driven automation workflows that can be triggered by alerts, schedules, or manual actions. They consist of one or more actions that run on specified hosts or clusters.
An administrator can obtain the following information from Plays:
Host where the action runs: Each action in a Play can be configured to run on a specific host or cluster, or on the host or cluster where the alert was triggered. The administrator can view the host or cluster name for each action in the Play details page.
Execution result status: Each action in a Play has an execution result status that indicates whether the action was successful, failed, skipped, or cancelled. The administrator can view the status for each action in the Play details page, as well as the overall status of the Play.
The other options are incorrect because:
Start time and end time of each action: Plays do not show the start time and end time of each action, only the duration of the action. The administrator can view the duration for each action in the Play details page, as well as the overall duration of the Play.
CVM IP where the alert was triggered: Plays do not show the CVM IP where the alert was triggered, only the host or cluster name where the alert was triggered. The administrator can view the host or cluster name for the alert in the Play details page.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) Exam Blueprint Guide, Section 1.2
Nutanix Multicloud Automation Administration (NMCAA) Course, Module 4: X-Play
Training Spotlight: Nutanix Multicloud Automation Administration (NMCAA), Video 4: X-Play
Reference: https://portal.nutanix.com/page/documents/solutions/details?targetId=Nutanix_Hybrid_Cloud_Reference_Architecture:top-incorporating-optional-nutanix-products-and-services.html
Question #8
A company wants to ensure that all developers are able to request new development environments on demand by using ServiceNow.
The administrator notices that even though developers create new environments, they rarely remove these environments when moving on to new assignments. Today, the administrator has gone into Prism Central to check when the VM was created, in order to reach out to the developer and ask if it can be deleted. The administrator has accidentally deleted the wrong VM in the past.
Which two methods can the administrator use to automate this task to avoid deleting the incorrect VMs? (Choose two.)
- A . Create a playbook REST API action to delete the VM from a ServiceNow approval flow.
- B . Create a playbook webhook action to delete the VM from a ServiceNow approval flow.
- C . Create a playbook webhook trigger to delete the VM from a ServiceNow approval flow.
- D . Create a playbook REST API trigger to delete the VM from a ServiceNow approval flow.
Correct Answer: A, B
A, B
Explanation:
A playbook REST API action allows the administrator to send an HTTP request to a specified endpoint, such as the Prism Central API, to perform an operation, such as deleting a VM. A playbook webhook action allows the administrator to send a payload to a specified URL, such as a ServiceNow webhook, to trigger an event, such as an approval flow. Both of these actions can be used to automate the deletion of VMs from a ServiceNow approval flow, where the developers can request and confirm the removal of their environments. A playbook webhook trigger and a playbook REST API trigger are not valid options, as they are used to initiate a playbook based on an external event, not to perform an action within a playbook.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) 6.5 Exam Blueprint Guide, page 10; Nutanix Certified Professional – Multicloud Automation (NCP-MCA), section 4; NCP-MCA Exam Dumps – Nutanix Certified Professional – Multicloud …, question 70.
Reference: https://portal.nutanix.com/page/documents/details?targetId=Prism-Central-Guide-Prism-v6_0:mul-service-now-configure-webhook-playbooks-pc-t.html
A, B
Explanation:
A playbook REST API action allows the administrator to send an HTTP request to a specified endpoint, such as the Prism Central API, to perform an operation, such as deleting a VM. A playbook webhook action allows the administrator to send a payload to a specified URL, such as a ServiceNow webhook, to trigger an event, such as an approval flow. Both of these actions can be used to automate the deletion of VMs from a ServiceNow approval flow, where the developers can request and confirm the removal of their environments. A playbook webhook trigger and a playbook REST API trigger are not valid options, as they are used to initiate a playbook based on an external event, not to perform an action within a playbook.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) 6.5 Exam Blueprint Guide, page 10; Nutanix Certified Professional – Multicloud Automation (NCP-MCA), section 4; NCP-MCA Exam Dumps – Nutanix Certified Professional – Multicloud …, question 70.
Reference: https://portal.nutanix.com/page/documents/details?targetId=Prism-Central-Guide-Prism-v6_0:mul-service-now-configure-webhook-playbooks-pc-t.html
Question #9
A developer has a Development Blueprint that performs the following high level items:
– Creates a Windows and Ubuntu Server.
– Installs IIS on Windows
– Installs MySQL on Ubuntu
As part of Development, there is a need for an Operator to restart IIS Services for troubleshooting purposes.
How should the developer add this functionality to the Blueprint?
- A . Add an Execute Task in the Restart Action of the Application Profile.
- B . Add an Execute Task in the Restart Action of the Windows/IIS Service.
- C . Add a Delay Task in the Restart Action of the Windows/IIS Service.
- D . Create an Endpoint for the IIS server and a Runbook that restarts the service.
Correct Answer: B
B
Explanation:
The Restart Action of a Service allows the developer to define custom tasks that will be executed when the service is restarted. An Execute Task can run any script or command on the target VM, such as restarting the IIS service. This way, the Operator can use the Self-Service Portal to restart the service without logging into the VM or using another tool.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) v6.5, Section 2, Objective 2.1: Given a scenario, create a blueprint to deploy infrastructure and applications using Self-Service. Nutanix Certified Professional Multicloud Automation (NCP-MCA) 6 Exam, Page 11, Section 2, Objective 2.1: Given a scenario, create a blueprint to deploy infrastructure and applications using Self-Service.
B
Explanation:
The Restart Action of a Service allows the developer to define custom tasks that will be executed when the service is restarted. An Execute Task can run any script or command on the target VM, such as restarting the IIS service. This way, the Operator can use the Self-Service Portal to restart the service without logging into the VM or using another tool.
Reference: Nutanix Certified Professional – Multicloud Automation (NCP-MCA) v6.5, Section 2, Objective 2.1: Given a scenario, create a blueprint to deploy infrastructure and applications using Self-Service. Nutanix Certified Professional Multicloud Automation (NCP-MCA) 6 Exam, Page 11, Section 2, Objective 2.1: Given a scenario, create a blueprint to deploy infrastructure and applications using Self-Service.
Question #10
An administrator has a Linux VM that does batch processing out of a queue. Currently, a technician connects to the VM console and runs a command on the VM to initiate or terminate the batch processing application, as there is no programmatic interface for the application.
The application is processor intensive, so it should only run outside of business hours. The VM has the ability to send REST API calls to Prism.
How should the administrator configure a Playbook to satisfy the needs of this process with minimal external interaction?
- A . Manual Trigger > Power On > VM SSH > Wait for Some Time > Power Off VM
- B . Time Trigger > VM SSH > Wait for Some Time > VM SSH
- C . Webhook Trigger > REST API > Wait for Some Time > REST API
- D . Manual Trigger > VM SSH > Wait for Some Time > VM SSH
Correct Answer: B
B
Explanation:
A Playbook is a collection of tasks that can be executed based on a trigger, such as a time, a webhook, or a manual action. A Playbook can be used to automate workflows across different systems and services, such as Nutanix Prism, VMs, hosts, and external APIs. A Playbook can also use variables, conditions, and loops to customize the execution logic and data.
In this scenario, the administrator wants to automate the batch processing application on the Linux VM, which can only be controlled by a command on the VM console. The application should run only outside of business hours, and the VM should send REST API calls to Prism to report its status.
The best way to configure a Playbook for this process is to use a Time Trigger, which allows the administrator to specify a schedule for the Playbook execution, such as daily, weekly, or monthly. The Time Trigger can also be configured to run only on certain days or hours, such as weekdays or nights. This way, the administrator can ensure that the Playbook runs only outside of business hours, without requiring any manual intervention.
The Playbook should then have two VM SSH tasks, one to initiate the batch processing application, and one to terminate it. A VM SSH task is a task that executes a command or script on a target VM using SSH. A VM SSH task can be used to control applications or services that do not have a programmatic interface, such as the batch processing application in this scenario. The VM SSH task can also use variables to pass data to or from the command or script, such as the VM name, IP address, or output.
The Playbook should also have a Wait for Some Time task, which is a task that pauses the Playbook execution for a specified duration or until a condition is met. A Wait for Some Time task can be used to ensure that the batch processing application has enough time to complete its work, or to wait for a certain event or state to occur, such as a file creation, a service status, or a VM power state.
The Playbook should also have two REST API tasks, one before and one after the Wait for Some Time task. A REST API task is a task that executes an HTTP request to a specified URL, with optional headers, body, and authentication. A REST API task can be used to interact with external systems or services that expose an API, such as Nutanix Prism in this scenario. The REST API task can also use variables to pass data to or from the HTTP request, such as the VM name, IP address, or response. The REST API tasks should be configured to send the VM status to Prism, such as the start and end time of the batch processing, the CPU and memory usage, or the output of the application. This way, the administrator can monitor and manage the VM and the application from Prism, without having to connect to the VM console.
The Playbook configuration should look something like this:
Time Trigger: Set the schedule to run daily, only on weekdays, and only at night (e.g., 10 PM to 6 AM).
VM SSH: Set the target VM to the Linux VM, and set the command or script to initiate the batch processing application (e.g., ./batch.sh start).
REST API: Set the URL to the Prism API endpoint, and set the HTTP method, headers, body, and authentication as required. Use variables to pass the VM name, IP address, and start time of the batch processing to the HTTP request (e.g., {"vm_name": "{{vm_name}}", "vm_ip": "{{vm_ip}}", "start_time": "{{start_time}}"}).
Wait for Some Time: Set the duration to the expected time for the batch processing to finish, or set a condition to wait until a certain event or state occurs (e.g., wait until file /tmp/batch.done exists). REST API: Set the URL to the Prism API endpoint, and set the HTTP method, headers, body, and authentication as required. Use variables to pass the VM name, IP address, end time, and output of the batch processing to the HTTP request (e.g., {"vm_name": "{{vm_name}}", "vm_ip": "{{vm_ip}}", "end_time": "{{end_time}}", "output": "{{output}}"}).
VM SSH: Set the target VM to the Linux VM, and set the command or script to terminate the batch processing application (e.g., ./batch.sh stop).
Reference:
https://www.nutanix.com/content/dam/nutanix/resources/datasheets/ds-ncp-mca-6-5.pdf
https://www.nutanix.com/content/dam/nutanix/resources/support/ds-ncp-mca.pdf
B
Explanation:
A Playbook is a collection of tasks that can be executed based on a trigger, such as a time, a webhook, or a manual action. A Playbook can be used to automate workflows across different systems and services, such as Nutanix Prism, VMs, hosts, and external APIs. A Playbook can also use variables, conditions, and loops to customize the execution logic and data.
In this scenario, the administrator wants to automate the batch processing application on the Linux VM, which can only be controlled by a command on the VM console. The application should run only outside of business hours, and the VM should send REST API calls to Prism to report its status.
The best way to configure a Playbook for this process is to use a Time Trigger, which allows the administrator to specify a schedule for the Playbook execution, such as daily, weekly, or monthly. The Time Trigger can also be configured to run only on certain days or hours, such as weekdays or nights. This way, the administrator can ensure that the Playbook runs only outside of business hours, without requiring any manual intervention.
The Playbook should then have two VM SSH tasks, one to initiate the batch processing application, and one to terminate it. A VM SSH task is a task that executes a command or script on a target VM using SSH. A VM SSH task can be used to control applications or services that do not have a programmatic interface, such as the batch processing application in this scenario. The VM SSH task can also use variables to pass data to or from the command or script, such as the VM name, IP address, or output.
The Playbook should also have a Wait for Some Time task, which is a task that pauses the Playbook execution for a specified duration or until a condition is met. A Wait for Some Time task can be used to ensure that the batch processing application has enough time to complete its work, or to wait for a certain event or state to occur, such as a file creation, a service status, or a VM power state.
The Playbook should also have two REST API tasks, one before and one after the Wait for Some Time task. A REST API task is a task that executes an HTTP request to a specified URL, with optional headers, body, and authentication. A REST API task can be used to interact with external systems or services that expose an API, such as Nutanix Prism in this scenario. The REST API task can also use variables to pass data to or from the HTTP request, such as the VM name, IP address, or response. The REST API tasks should be configured to send the VM status to Prism, such as the start and end time of the batch processing, the CPU and memory usage, or the output of the application. This way, the administrator can monitor and manage the VM and the application from Prism, without having to connect to the VM console.
The Playbook configuration should look something like this:
Time Trigger: Set the schedule to run daily, only on weekdays, and only at night (e.g., 10 PM to 6 AM).
VM SSH: Set the target VM to the Linux VM, and set the command or script to initiate the batch processing application (e.g., ./batch.sh start).
REST API: Set the URL to the Prism API endpoint, and set the HTTP method, headers, body, and authentication as required. Use variables to pass the VM name, IP address, and start time of the batch processing to the HTTP request (e.g., {"vm_name": "{{vm_name}}", "vm_ip": "{{vm_ip}}", "start_time": "{{start_time}}"}).
Wait for Some Time: Set the duration to the expected time for the batch processing to finish, or set a condition to wait until a certain event or state occurs (e.g., wait until file /tmp/batch.done exists). REST API: Set the URL to the Prism API endpoint, and set the HTTP method, headers, body, and authentication as required. Use variables to pass the VM name, IP address, end time, and output of the batch processing to the HTTP request (e.g., {"vm_name": "{{vm_name}}", "vm_ip": "{{vm_ip}}", "end_time": "{{end_time}}", "output": "{{output}}"}).
VM SSH: Set the target VM to the Linux VM, and set the command or script to terminate the batch processing application (e.g., ./batch.sh stop).
Reference:
https://www.nutanix.com/content/dam/nutanix/resources/datasheets/ds-ncp-mca-6-5.pdf
https://www.nutanix.com/content/dam/nutanix/resources/support/ds-ncp-mca.pdf