Guest

Cisco UCS Manager CLI Configuration Guide, Release 2.1

Book Contents
Find Matches in This Book
Available Languages
Download Options

Book Title

Cisco UCS Manager CLI Configuration Guide, Release 2.1

Chapter Title

Deferring Deployment of Service Profile Updates

Results

Updated:
February 17, 2015

Chapter: Deferring Deployment of Service Profile Updates

Contents

Deferring Deployment of Service Profile Updates

This chapter includes the following sections:

Deferred Deployment of Service Profiles

Some modifications to a service profile or to an updating service profile template can be disruptive and require a reboot of the server. You can, however, configure deferred deployment to control when those disruptive configuration changes are implemented. For example, you can choose to deploy the service profile changes immediately or have them deployed during a specified maintenance window. You can also choose whether or not a service profile deployment requires explicit user acknowledgement.

Deferred deployment is available for all configuration changes that occur through the association of a service profile with a server. These configuration changes can be prompted by a change to a service profile, to a policy that is included in a service profile, or to an updating service profile template. For example, you can defer the upgrade and activation of firmware through host firmware packages and management firmware packages, such as server BIOS, RAID controller, host HBA, and network adapters. However, you cannot defer the direct deployment of firmware images for components that do not use either of the firmware packages, such as Cisco UCS Manager, fabric interconnects, and I/O modules.

Deferred deployment is not available for the following actions which require the reboot of a server:

  • Initial association of a service profile with a server

  • Final disassociation of a service profile from a server, without associating the service profile with a different server

  • Decommissioning a server

  • Reacknowledging a server

  • Resetting a server

If you want to defer the deployment of service profile changes, you must configure one or more maintenance policies and configure each service profile with a maintenance policy. If you want to define the time period when the deployment should occur, you also need to create at least one schedule with one or more recurring occurrences or one time occurrences, and include that schedule in a maintenance policy.

Deferred Deployment Schedules

A schedule contains a set of occurrences. These occurrences can be one time only or can recur at a specified time and day each week. The options defined in the occurrence, such as the duration of the occurrence or the maximum number of tasks to be run, determine whether a service profile change is deployed. For example, if a change cannot be deployed during a given maintenance window because the maximum duration or number of tasks has been reached, that deployment is carried over to the next maintenance window.

Each schedule checks periodically to see whether the Cisco UCS domain has entered one or more maintenance windows. If it has, the schedule executes the deployments that are eligible according to the constraints specified in the maintenance policy

A schedule contains one or more occurrences, which determine the maintenance windows associated with that schedule. An occurrence can be one of the following:

One Time Occurrence

One time occurrences define a single maintenance window. These windows continue until the maximum duration of the window or the maximum number of tasks that can be run in the window has been reached.

Recurring Occurrence

Recurring occurrences define a series of maintenance windows. These windows continue until the maximum number of tasks or the end of the day specified in the occurrence has been reached.

Maintenance Policy

A maintenance policy determines how Cisco UCS Manager reacts when a change that requires a server reboot is made to a service profile associated with a server or to an updating service profile bound to one or more service profiles.

The maintenance policy specifies how Cisco UCS Manager deploys the service profile changes. The deployment can occur in one of the following ways:

  • Immediately

  • When acknowledged by a user with admin privileges

  • Automatically at the time specified in a schedule

If the maintenance policy is configured to deploy the change during a scheduled maintenance window, the policy must include a valid schedule. The schedule deploys the changes in the first available maintenance window.


Note
A maintenance policy only prevents an immediate server reboot when a configuration change is made to an associated service profile. However, a maintenance policy does not prevent the following actions from taking place right away:

  • Deleting an associated service profile from the system

  • Disassociating a server profile from a server

  • Directly installing a firmware upgrade without using a service policy

  • Resetting the server

Pending Activities

If you configure deferred deployment in a Cisco UCS domain, Cisco UCS Manager enables you to view all pending activities. You can see activities that are waiting for user acknowledgement and those that have been scheduled.

If a Cisco UCS domain has pending activities, Cisco UCS Manager GUI notifies users with admin privileges when they log in.

Cisco UCS Manager displays information about all pending activities, including the following:

  • Name of the service profile to be deployed and associated with a server

  • Server affected by the deployment

  • Disruption caused by the deployment

  • Change performed by the deployment


Note

You cannot specify the maintenance window in which a specific pending activity is applied to the server. The maintenance window depends upon how many activities are pending and which maintenance policy is assigned to the service profile. However, any user with admin privileges can manually initiate a pending activity and reboot the server immediately, whether it is waiting for user acknowledgment or for a maintenance window.

Guidelines and Limitations for Deferred Deployment

Cannot Undo All Changes to Service Profiles or Service Profile Templates

If you cancel a pending change, Cisco UCS Manager attempts to roll back the change without rebooting the server. However, for complex changes, Cisco UCS Manager may have to reboot the server a second time to roll back the change. For example, if you delete a vNIC, Cisco UCS Manager reboots the server according to the maintenance policy included in the service profile. You cannot cancel this reboot and change, even if you restore the original vNIC in the service profile. Instead, Cisco UCS Manager schedules a second deployment and reboot of the server.

Association of Service Profile Can Exceed Boundaries of Maintenance Window

After Cisco UCS Manager begins the association of the service profile, the scheduler and maintenance policy do not have any control over the procedure. If the service profile association does not complete within the allotted maintenance window, the process continues until it is completed. For example, this can occur if the association does not complete in time because of retried stages or other issues.

Cannot Specify Order of Pending Activities

Scheduled deployments run in parallel and independently. You cannot specify the order in which the deployments occur. You also cannot make the deployment of one service profile change dependent upon the completion of another.

Cannot Perform Partial Deployment of Pending Activity

Cisco UCS Manager applies all changes made to a service profile in the scheduled maintenance window. You cannot make several changes to a service profile at the same time and then have those changes be spread across several maintenance windows. When Cisco UCS Manager deploys the service profile changes, it updates the service profile to match the most recent configuration in the database.

Configuring Schedules

Creating a Schedule

Procedure
     Command or ActionPurpose
    Step 1 UCS-A# scope system  

    Enters system mode.

     
    Step 2 UCS-A /system # create scheduler sched-name  

    Creates a scheduler and enters scheduler mode.

     
    Step 3 UCS-A /system/scheduler # commit-buffer  

    Commits the transaction to the system configuration.

     

    The following example creates a scheduler called maintenancesched and commits the transaction:

    UCS-A# scope system
UCS-A /system # create scheduler maintenancesched
UCS-A /system/scheduler* # commit-buffer
UCS-A /system/scheduler #
    What to Do Next

    Create a one time occurrence or recurring occurrence for the schedule.

    Creating a One Time Occurrence for a Schedule

    Procedure
       Command or ActionPurpose
      Step 1 UCS-A# scope system  

      Enters system mode.

       
      Step 2 UCS-A /system # scope schedule sched-name  

      Enters scheduler system mode.

       
      Step 3 UCS-A /system/scheduler # create occurrence one-time occurrence-name  

      Creates a one-time occurrence.

       
      Step 4 UCS-A /system/scheduler/one-time # set date month day-of-month year hour minute  

      Sets the date and time this occurrence should run.

       
      Step 5 UCS-A /system/scheduler/one-time # set concur-tasks {unlimited | max-num-concur-tasks   (Optional)

      Sets the maximum number of tasks that can run concurrently during this occurrence.

      If the maximum number of tasks is reached, the scheduler waits for the amount of time set in the minimum interval property before scheduling new tasks.

       
      Step 6 UCS-A /system/scheduler/one-time # set max-duration {none | num-of-days num-of-hours num-of-minutes num-of-seconds}   (Optional)

      Sets the maximum length of time that this schedule occurrence can run. Cisco UCS completes as many scheduled tasks as possible within the specified time.

       
      Step 7 UCS-A /system/scheduler/one-time # set min-interval {none | num-of-days num-of-hours num-of-minutes num-of-seconds}   (Optional)

      Sets the minimum length of time that the system should wait before starting a new task.

       
      Step 8 UCS-A /system/scheduler/one-time # set proc-cap {unlimited | max-num-of-tasks}   (Optional)

      Sets the maximum number of scheduled tasks that can be run during this occurrence.

       
      Step 9 UCS-A /system/scheduler/one-time # commit-buffer  

      Commits the transaction to the system configuration.

       
      The following example creates a one time occurrence called onetimemaint for a scheduler called maintsched, sets the maximum number of concurrent tasks to 5, sets the start date to April 1, 2011 at 11:00, and commits the transaction:
      UCS-A# scope system
UCS-A /system # scope scheduler maintsched
UCS-A /system/scheduler # create occurrence one-time onetimemaint
UCS-A /system/scheduler/one-time* # set date apr 1 2011 11 00
UCS-A /system/scheduler/one-time* # set concur-tasks 5
UCS-A /system/scheduler/one-time* # commit-buffer
UCS-A /system/scheduler/one-time #

      Creating a Recurring Occurrence for a Schedule

      Procedure
         Command or ActionPurpose
        Step 1 UCS-A# scope system  

        Enters system mode.

         
        Step 2 UCS-A /system # scope schedule sched-name  

        Enters scheduler system mode.

         
        Step 3 UCS-A /system/scheduler # create occurrence recurring occurrence-name  

        Creates a recurring occurrence.

         
        Step 4 UCS-A /system/scheduler/recurring # set day {even-day | every-day | friday | monday | never | odd-day | saturday | sunday | thursday | tuesday | wednesday}   (Optional)

        Specifies the day on which Cisco UCS runs an occurrence of this schedule.

        By default, this property is set to never.

         
        Step 5 UCS-A /system/scheduler/recurring # set hour hour   (Optional)

        Specifies the hour at which this occurrence starts.

        Note   

        Cisco UCS ends all recurring occurrences on the same day in which they start, even if the maximum duration has not been reached. For example, if you specify a start time of 11 p.m. and a maximum duration of 3 hours, Cisco UCS starts the occurrence at 11 p.m. but ends it at 11:59 p.m. after only 59 minutes.

         
        Step 6 UCS-A /system/scheduler/recurring # set minute minute   (Optional)

        Specifies the minute at which this occurrence starts.

         
        Step 7 UCS-A /system/scheduler/recurring # set concur-tasks {unlimited | max-num-concur-tasks   (Optional)

        Sets the maximum number of tasks that can run concurrently during this occurrence.

        If the maximum number of tasks is reached, the scheduler waits for the amount of time set in the minimum interval property before scheduling new tasks.

         
        Step 8 UCS-A /system/scheduler/recurring # set max-duration {none | num-of-hours num-of-minutes num-of-seconds}   (Optional)

        Sets the maximum length of time that this schedule occurrence can run. Cisco UCS completes as many scheduled tasks as possible within the specified time.

         
        Step 9 UCS-A /system/scheduler/recurring # set min-interval {none | num-of-days num-of-hours num-of-minutes num-of-seconds}   (Optional)

        Sets the minimum length of time that the system should wait before starting a new task.

         
        Step 10 UCS-A /system/scheduler/recurring # set proc-cap {unlimited | max-num-of-tasks}   (Optional)

        Sets the maximum number of scheduled tasks that can be run during this occurrence.

         
        Step 11 UCS-A /system/scheduler/recurring # commit-buffer  

        Commits the transaction to the system configuration.

         
        The following example creates a recurring occurrence called recurringmaint for a scheduler called maintsched, sets the maximum number of concurrent tasks to 5, sets the day this occurrence will run to even days, sets the time it will start to 11:05, and commits the transaction:
        UCS-A# scope system
UCS-A /system # scope scheduler maintsched
UCS-A /system/scheduler # create occurrence recurring recurringmaint
UCS-A /system/scheduler/recurring* # set day even-day
UCS-A /system/scheduler/recurring* # set hour 11
UCS-A /system/scheduler/recurring* # set minute 5
UCS-A /system/scheduler/recurring* # set concur-tasks 5
UCS-A /system/scheduler/recurring* # commit-buffer
UCS-A /system/scheduler/recurring #

        Deleting a One Time Occurrence from a Schedule

        If this is the only occurrence in a schedule, that schedule is reconfigured with no occurrences. If the schedule is included in a maintenance policy and that policy is assigned to a service profile, any pending activities related to the server associated with the service profile cannot be deployed. You must add a one time ocurrence or a recurring occurrence to the schedule to deploy the pending activity.

        Procedure
           Command or ActionPurpose
          Step 1 UCS-A# scope system  

          Enters system mode.

           
          Step 2 UCS-A /system # scope scheduler sched-name  

          Enters scheduler system mode.

           
          Step 3 UCS-A /system/scheduler # delete occurrence one-time occurrence-name  

          Deletes the specified one-time occurrence.

           
          Step 4 UCS-A /system/scheduler # commit-buffer  

          Commits the transaction to the system configuration.

           
          The following example deletes a one time occurrence called onetimemaint from scheduler maintsched and commits the transaction:
          UCS-A# scope system
UCS-A /system # scope scheduler maintsched
UCS-A /system/scheduler # delete occurrence one-time onetimemaint
UCS-A /system/scheduler* # commit-buffer
UCS-A /system/scheduler #

          Deleting a Recurring Occurrence from a Schedule

          If this is the only occurrence in a schedule, that schedule is reconfigured with no occurrences. If the schedule is included in a maintenance policy and that policy is assigned to a service profile, any pending activities related to the server associated with the service profile cannot be deployed. You must add a one time ocurrence or a recurring occurrence to the schedule to deploy the pending activity.

          Procedure
             Command or ActionPurpose
            Step 1 UCS-A# scope system  

            Enters system mode.

             
            Step 2 UCS-A /system # scope scheduler sched-name  

            Enters scheduler system mode.

             
            Step 3 UCS-A /system/scheduler # delete occurrence recurring occurrence-name  

            Deletes the specified recurring occurrence.

             
            Step 4 UCS-A /system/scheduler # commit-buffer  

            Commits the transaction to the system configuration.

             
            The following example deletes a recurring occurrence called onetimemaint from scheduler maintsched and commits the transaction:
            UCS-A# scope system
UCS-A /system # scope scheduler maintsched
UCS-A /system/scheduler # delete occurrence recurring onetimemaint
UCS-A /system/scheduler* # commit-buffer
UCS-A /system/scheduler #

            Deleting a Schedule

            If this schedule is included in a maintenance policy, the policy is reconfigured with no schedule. If that policy is assigned to a service profile, any pending activities related to the server associated with the service profile cannot be deployed. You must add a schedule to the maintenance policy to deploy the pending activity.

            Procedure
               Command or ActionPurpose
              Step 1 UCS-A# scope system  

              Enters system mode.

               
              Step 2 UCS-A /system # delete scheduler sched-name  

              Deletes a scheduler and enters scheduler mode.

               
              Step 3 UCS-A /system # commit-buffer  

              Commits the transaction to the system configuration.

               

              The following example deletes a scheduler called maintenancesched and commits the transaction:

              UCS-A# scope system
UCS-A /system # delete scheduler maintenancesched
UCS-A /system* # commit-buffer
UCS-A /system #

              Configuring Maintenance Policies

              Creating a Maintenance Policy

              Before You Begin

              If you plan to configure this maintenance policy for deferred deployment, create a schedule.

              Procedure
                 Command or ActionPurpose
                Step 1UCS-A# scope org org-name  

                Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .

                 
                Step 2UCS-A /org # create maint-policy policy-name  

                Creates the specified maintenance policy and enters maintenance policy mode.

                 
                Step 3UCS-A /org/maint-policy # set reboot-policy {immediate | timer-automatic | user-ack}  
                When a service profile is associated with a server, the server needs to be rebooted to complete the association. Specifying the reboot-policy command determines when the reboot occurs for all service profiles that include this maintenance policy. Possible values include:

                • immediate--The server reboots as soon as the change is made to the service profile.

                • timer-automatic --You select the schedule that specifies when maintenance operations can be applied to the server using the set scheduler command. Cisco UCS reboots the server and completes the service profile changes at the scheduled time.

                • user-ack --The user must explicitly acknowledge the changes by using the apply pending-changes command before changes are applied.

                 
                Step 4UCS-A /org/maint-policy # set scheduler scheduler-name   (Optional)

                If the reboot-policy property is set to timer-automatic, you must select the schedule that specifies when maintenance operations can be applied to the server. Cisco UCS reboots the server and completes the service profile changes at the scheduled time.

                 
                Step 5UCS-A /org/maint-policy # commit-buffer  

                Commits the transaction to the system configuration.

                 
                The following example creates a maintenance policy called maintenance, sets the system to reboot immediately when a service profile is associated with a server, and commits the transaction:
                UCS-A# scope org /
UCS-A /org # create maint-policy maintenance
UCS-A /org/maint-policy* # set reboot-policy immediate
UCS-A /org/maint-policy* # commit-buffer
UCS-A /org/maint-policy #

                Deleting a Maintenance Policy

                Procedure
                   Command or ActionPurpose
                  Step 1UCS-A# scope org org-name  

                  Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .

                   
                  Step 2UCS-A /org # delete maint-policy policy-name  

                  Deletes the specified maintenance policy.

                   
                  Step 3UCS-A /org # commit-buffer  

                  Commits the transaction to the system configuration.

                   
                  The following example deletes a maintenance policy called maintenance and commits the transaction:
                  UCS-A# scope org /
UCS-A /org # delete maint-policy maintenance
UCS-A /org/maint-policy* # commit-buffer
UCS-A /org/maint-policy #

                  Managing Pending Activities

                  Viewing Pending Activities

                  Procedure
                     Command or ActionPurpose
                    Step 1 UCS-A# scope org org-name  

                    Enters organization mode.

                    To enter the root organization mode, type / as the org-name.

                     
                    Step 2 UCS-A /org # scope service-profile profile-name  

                    Enters organization service profile mode for the specified service.

                     
                    Step 3 UCS-A /org/service-profile # show pending-changes [detail | expand]  

                    Displays details about pending-changes.

                     

                    The following example shows how to display pending changes for a service profile called accounting:

                    UCS-A# scope org /
UCS-A /org # scope service-profile accounting
UCS-A /org/service-profile # show pending-changes detail

Pending Changes:
    Scheduler:
    Changed by: admin
    Acked by:
    Mod. date: 2010-09-20T20:36:09.254
    State: Untriggered
    Admin State: Untriggered
    Pend. Changes: 0
    Pend. Disr.: 0
UCS-A /org/service-profile #

                    Deploying a Service Profile Change Waiting for User Acknowledgement

                    Cisco UCS Manager CLI cannot deploy all pending service profile changes (for multiple service profiles) waiting for user acknowledgement. To simultaneously deploy all pending service profile changes for multiple service profiles, use Cisco UCS Manager GUI.
                    Important:

                    You cannot stop Cisco UCS Manager from rebooting the affected server after you acknowledge a pending activity.

                    Procedure
                       Command or ActionPurpose
                      Step 1 UCS-A# scope org org-name  

                      Enters organization mode.

                      To enter the root organization mode, type / as the org-name.

                       
                      Step 2 UCS-A /org # scope service-profile profile-name  

                      Enters organization service profile mode for the specified service.

                       
                      Step 3 UCS-A /org/service-profile # apply pending-changes immediate  

                      Applies the pending changes immediately.

                      Cisco UCS Manager immediately reboots the server affected by the pending activity.

                       

                      The following example shows how to apply pending changes for a service profile called accounting:

                      UCS-A# scope org /
UCS-A /org # scope service-profile accounting
UCS-A /org/service-profile # apply pending-changes immediate
UCS-A /org/service-profile #

                      Deploying a Scheduled Service Profile Change Immediately

                      Cisco UCS Manager CLI cannot deploy all scheduled service profile changes (for multiple service profiles) at the same time. To simultaneously deploy all scheduled service profile changes for multiple service profiles, use Cisco UCS Manager GUI.
                      Important:

                      You cannot stop Cisco UCS Manager from rebooting the affected server after you acknowledge a pending activity.

                      Procedure
                         Command or ActionPurpose
                        Step 1 UCS-A# scope org org-name  

                        Enters organization mode.

                        To enter the root organization mode, type / as the org-name.

                         
                        Step 2 UCS-A /org # scope service-profile profile-name  

                        Enters organization service profile mode for the specified service.

                         
                        Step 3 UCS-A /org/service-profile # apply pending-changes immediate  

                        Applies the pending changes immediately.

                        Cisco UCS Manager immediately reboots the server affected by the pending activity.

                         

                        The following example shows how to apply pending changes for a service profile called accounting:

                        UCS-A# scope org /
UCS-A /org # scope service-profile accounting
UCS-A /org/service-profile # apply pending-changes immediate
UCS-A /org/service-profile #
                        Deferring Deployment of Service Profile Updates

                        Deferring Deployment of Service Profile Updates

                        This chapter includes the following sections:

                        Deferred Deployment of Service Profiles

                        Some modifications to a service profile or to an updating service profile template can be disruptive and require a reboot of the server. You can, however, configure deferred deployment to control when those disruptive configuration changes are implemented. For example, you can choose to deploy the service profile changes immediately or have them deployed during a specified maintenance window. You can also choose whether or not a service profile deployment requires explicit user acknowledgement.

                        Deferred deployment is available for all configuration changes that occur through the association of a service profile with a server. These configuration changes can be prompted by a change to a service profile, to a policy that is included in a service profile, or to an updating service profile template. For example, you can defer the upgrade and activation of firmware through host firmware packages and management firmware packages, such as server BIOS, RAID controller, host HBA, and network adapters. However, you cannot defer the direct deployment of firmware images for components that do not use either of the firmware packages, such as Cisco UCS Manager, fabric interconnects, and I/O modules.

                        Deferred deployment is not available for the following actions which require the reboot of a server:

                        • Initial association of a service profile with a server

                        • Final disassociation of a service profile from a server, without associating the service profile with a different server

                        • Decommissioning a server

                        • Reacknowledging a server

                        • Resetting a server

                        If you want to defer the deployment of service profile changes, you must configure one or more maintenance policies and configure each service profile with a maintenance policy. If you want to define the time period when the deployment should occur, you also need to create at least one schedule with one or more recurring occurrences or one time occurrences, and include that schedule in a maintenance policy.

                        Deferred Deployment Schedules

                        A schedule contains a set of occurrences. These occurrences can be one time only or can recur at a specified time and day each week. The options defined in the occurrence, such as the duration of the occurrence or the maximum number of tasks to be run, determine whether a service profile change is deployed. For example, if a change cannot be deployed during a given maintenance window because the maximum duration or number of tasks has been reached, that deployment is carried over to the next maintenance window.

                        Each schedule checks periodically to see whether the Cisco UCS domain has entered one or more maintenance windows. If it has, the schedule executes the deployments that are eligible according to the constraints specified in the maintenance policy

                        A schedule contains one or more occurrences, which determine the maintenance windows associated with that schedule. An occurrence can be one of the following:

                        One Time Occurrence

                        One time occurrences define a single maintenance window. These windows continue until the maximum duration of the window or the maximum number of tasks that can be run in the window has been reached.

                        Recurring Occurrence

                        Recurring occurrences define a series of maintenance windows. These windows continue until the maximum number of tasks or the end of the day specified in the occurrence has been reached.

                        Maintenance Policy

                        A maintenance policy determines how Cisco UCS Manager reacts when a change that requires a server reboot is made to a service profile associated with a server or to an updating service profile bound to one or more service profiles.

                        The maintenance policy specifies how Cisco UCS Manager deploys the service profile changes. The deployment can occur in one of the following ways:

                        • Immediately

                        • When acknowledged by a user with admin privileges

                        • Automatically at the time specified in a schedule

                        If the maintenance policy is configured to deploy the change during a scheduled maintenance window, the policy must include a valid schedule. The schedule deploys the changes in the first available maintenance window.


                        Note
                        A maintenance policy only prevents an immediate server reboot when a configuration change is made to an associated service profile. However, a maintenance policy does not prevent the following actions from taking place right away:

                        • Deleting an associated service profile from the system

                        • Disassociating a server profile from a server

                        • Directly installing a firmware upgrade without using a service policy

                        • Resetting the server

                        Pending Activities

                        If you configure deferred deployment in a Cisco UCS domain, Cisco UCS Manager enables you to view all pending activities. You can see activities that are waiting for user acknowledgement and those that have been scheduled.

                        If a Cisco UCS domain has pending activities, Cisco UCS Manager GUI notifies users with admin privileges when they log in.

                        Cisco UCS Manager displays information about all pending activities, including the following:

                        • Name of the service profile to be deployed and associated with a server

                        • Server affected by the deployment

                        • Disruption caused by the deployment

                        • Change performed by the deployment


                        Note

                        You cannot specify the maintenance window in which a specific pending activity is applied to the server. The maintenance window depends upon how many activities are pending and which maintenance policy is assigned to the service profile. However, any user with admin privileges can manually initiate a pending activity and reboot the server immediately, whether it is waiting for user acknowledgment or for a maintenance window.

                        Guidelines and Limitations for Deferred Deployment

                        Cannot Undo All Changes to Service Profiles or Service Profile Templates

                        If you cancel a pending change, Cisco UCS Manager attempts to roll back the change without rebooting the server. However, for complex changes, Cisco UCS Manager may have to reboot the server a second time to roll back the change. For example, if you delete a vNIC, Cisco UCS Manager reboots the server according to the maintenance policy included in the service profile. You cannot cancel this reboot and change, even if you restore the original vNIC in the service profile. Instead, Cisco UCS Manager schedules a second deployment and reboot of the server.

                        Association of Service Profile Can Exceed Boundaries of Maintenance Window

                        After Cisco UCS Manager begins the association of the service profile, the scheduler and maintenance policy do not have any control over the procedure. If the service profile association does not complete within the allotted maintenance window, the process continues until it is completed. For example, this can occur if the association does not complete in time because of retried stages or other issues.

                        Cannot Specify Order of Pending Activities

                        Scheduled deployments run in parallel and independently. You cannot specify the order in which the deployments occur. You also cannot make the deployment of one service profile change dependent upon the completion of another.

                        Cannot Perform Partial Deployment of Pending Activity

                        Cisco UCS Manager applies all changes made to a service profile in the scheduled maintenance window. You cannot make several changes to a service profile at the same time and then have those changes be spread across several maintenance windows. When Cisco UCS Manager deploys the service profile changes, it updates the service profile to match the most recent configuration in the database.

                        Configuring Schedules

                        Creating a Schedule

                        Procedure
                           Command or ActionPurpose
                          Step 1 UCS-A# scope system  

                          Enters system mode.

                           
                          Step 2 UCS-A /system # create scheduler sched-name  

                          Creates a scheduler and enters scheduler mode.

                           
                          Step 3 UCS-A /system/scheduler # commit-buffer  

                          Commits the transaction to the system configuration.

                           

                          The following example creates a scheduler called maintenancesched and commits the transaction:

                          UCS-A# scope system
UCS-A /system # create scheduler maintenancesched
UCS-A /system/scheduler* # commit-buffer
UCS-A /system/scheduler #
                          What to Do Next

                          Create a one time occurrence or recurring occurrence for the schedule.

                          Creating a One Time Occurrence for a Schedule

                          Procedure
                             Command or ActionPurpose
                            Step 1 UCS-A# scope system  

                            Enters system mode.

                             
                            Step 2 UCS-A /system # scope schedule sched-name  

                            Enters scheduler system mode.

                             
                            Step 3 UCS-A /system/scheduler # create occurrence one-time occurrence-name  

                            Creates a one-time occurrence.

                             
                            Step 4 UCS-A /system/scheduler/one-time # set date month day-of-month year hour minute  

                            Sets the date and time this occurrence should run.

                             
                            Step 5 UCS-A /system/scheduler/one-time # set concur-tasks {unlimited | max-num-concur-tasks   (Optional)

                            Sets the maximum number of tasks that can run concurrently during this occurrence.

                            If the maximum number of tasks is reached, the scheduler waits for the amount of time set in the minimum interval property before scheduling new tasks.

                             
                            Step 6 UCS-A /system/scheduler/one-time # set max-duration {none | num-of-days num-of-hours num-of-minutes num-of-seconds}   (Optional)

                            Sets the maximum length of time that this schedule occurrence can run. Cisco UCS completes as many scheduled tasks as possible within the specified time.

                             
                            Step 7 UCS-A /system/scheduler/one-time # set min-interval {none | num-of-days num-of-hours num-of-minutes num-of-seconds}   (Optional)

                            Sets the minimum length of time that the system should wait before starting a new task.

                             
                            Step 8 UCS-A /system/scheduler/one-time # set proc-cap {unlimited | max-num-of-tasks}   (Optional)

                            Sets the maximum number of scheduled tasks that can be run during this occurrence.

                             
                            Step 9 UCS-A /system/scheduler/one-time # commit-buffer  

                            Commits the transaction to the system configuration.

                             
                            The following example creates a one time occurrence called onetimemaint for a scheduler called maintsched, sets the maximum number of concurrent tasks to 5, sets the start date to April 1, 2011 at 11:00, and commits the transaction:
                            UCS-A# scope system
UCS-A /system # scope scheduler maintsched
UCS-A /system/scheduler # create occurrence one-time onetimemaint
UCS-A /system/scheduler/one-time* # set date apr 1 2011 11 00
UCS-A /system/scheduler/one-time* # set concur-tasks 5
UCS-A /system/scheduler/one-time* # commit-buffer
UCS-A /system/scheduler/one-time #

                            Creating a Recurring Occurrence for a Schedule

                            Procedure
                               Command or ActionPurpose
                              Step 1 UCS-A# scope system  

                              Enters system mode.

                               
                              Step 2 UCS-A /system # scope schedule sched-name  

                              Enters scheduler system mode.

                               
                              Step 3 UCS-A /system/scheduler # create occurrence recurring occurrence-name  

                              Creates a recurring occurrence.

                               
                              Step 4 UCS-A /system/scheduler/recurring # set day {even-day | every-day | friday | monday | never | odd-day | saturday | sunday | thursday | tuesday | wednesday}   (Optional)

                              Specifies the day on which Cisco UCS runs an occurrence of this schedule.

                              By default, this property is set to never.

                               
                              Step 5 UCS-A /system/scheduler/recurring # set hour hour   (Optional)

                              Specifies the hour at which this occurrence starts.

                              Note   

                              Cisco UCS ends all recurring occurrences on the same day in which they start, even if the maximum duration has not been reached. For example, if you specify a start time of 11 p.m. and a maximum duration of 3 hours, Cisco UCS starts the occurrence at 11 p.m. but ends it at 11:59 p.m. after only 59 minutes.

                               
                              Step 6 UCS-A /system/scheduler/recurring # set minute minute   (Optional)

                              Specifies the minute at which this occurrence starts.

                               
                              Step 7 UCS-A /system/scheduler/recurring # set concur-tasks {unlimited | max-num-concur-tasks   (Optional)

                              Sets the maximum number of tasks that can run concurrently during this occurrence.

                              If the maximum number of tasks is reached, the scheduler waits for the amount of time set in the minimum interval property before scheduling new tasks.

                               
                              Step 8 UCS-A /system/scheduler/recurring # set max-duration {none | num-of-hours num-of-minutes num-of-seconds}   (Optional)

                              Sets the maximum length of time that this schedule occurrence can run. Cisco UCS completes as many scheduled tasks as possible within the specified time.

                               
                              Step 9 UCS-A /system/scheduler/recurring # set min-interval {none | num-of-days num-of-hours num-of-minutes num-of-seconds}   (Optional)

                              Sets the minimum length of time that the system should wait before starting a new task.

                               
                              Step 10 UCS-A /system/scheduler/recurring # set proc-cap {unlimited | max-num-of-tasks}   (Optional)

                              Sets the maximum number of scheduled tasks that can be run during this occurrence.

                               
                              Step 11 UCS-A /system/scheduler/recurring # commit-buffer  

                              Commits the transaction to the system configuration.

                               
                              The following example creates a recurring occurrence called recurringmaint for a scheduler called maintsched, sets the maximum number of concurrent tasks to 5, sets the day this occurrence will run to even days, sets the time it will start to 11:05, and commits the transaction:
                              UCS-A# scope system
UCS-A /system # scope scheduler maintsched
UCS-A /system/scheduler # create occurrence recurring recurringmaint
UCS-A /system/scheduler/recurring* # set day even-day
UCS-A /system/scheduler/recurring* # set hour 11
UCS-A /system/scheduler/recurring* # set minute 5
UCS-A /system/scheduler/recurring* # set concur-tasks 5
UCS-A /system/scheduler/recurring* # commit-buffer
UCS-A /system/scheduler/recurring #

                              Deleting a One Time Occurrence from a Schedule

                              If this is the only occurrence in a schedule, that schedule is reconfigured with no occurrences. If the schedule is included in a maintenance policy and that policy is assigned to a service profile, any pending activities related to the server associated with the service profile cannot be deployed. You must add a one time ocurrence or a recurring occurrence to the schedule to deploy the pending activity.

                              Procedure
                                 Command or ActionPurpose
                                Step 1 UCS-A# scope system  

                                Enters system mode.

                                 
                                Step 2 UCS-A /system # scope scheduler sched-name  

                                Enters scheduler system mode.

                                 
                                Step 3 UCS-A /system/scheduler # delete occurrence one-time occurrence-name  

                                Deletes the specified one-time occurrence.

                                 
                                Step 4 UCS-A /system/scheduler # commit-buffer  

                                Commits the transaction to the system configuration.

                                 
                                The following example deletes a one time occurrence called onetimemaint from scheduler maintsched and commits the transaction:
                                UCS-A# scope system
UCS-A /system # scope scheduler maintsched
UCS-A /system/scheduler # delete occurrence one-time onetimemaint
UCS-A /system/scheduler* # commit-buffer
UCS-A /system/scheduler #

                                Deleting a Recurring Occurrence from a Schedule

                                If this is the only occurrence in a schedule, that schedule is reconfigured with no occurrences. If the schedule is included in a maintenance policy and that policy is assigned to a service profile, any pending activities related to the server associated with the service profile cannot be deployed. You must add a one time ocurrence or a recurring occurrence to the schedule to deploy the pending activity.

                                Procedure
                                   Command or ActionPurpose
                                  Step 1 UCS-A# scope system  

                                  Enters system mode.

                                   
                                  Step 2 UCS-A /system # scope scheduler sched-name  

                                  Enters scheduler system mode.

                                   
                                  Step 3 UCS-A /system/scheduler # delete occurrence recurring occurrence-name  

                                  Deletes the specified recurring occurrence.

                                   
                                  Step 4 UCS-A /system/scheduler # commit-buffer  

                                  Commits the transaction to the system configuration.

                                   
                                  The following example deletes a recurring occurrence called onetimemaint from scheduler maintsched and commits the transaction:
                                  UCS-A# scope system
UCS-A /system # scope scheduler maintsched
UCS-A /system/scheduler # delete occurrence recurring onetimemaint
UCS-A /system/scheduler* # commit-buffer
UCS-A /system/scheduler #

                                  Deleting a Schedule

                                  If this schedule is included in a maintenance policy, the policy is reconfigured with no schedule. If that policy is assigned to a service profile, any pending activities related to the server associated with the service profile cannot be deployed. You must add a schedule to the maintenance policy to deploy the pending activity.

                                  Procedure
                                     Command or ActionPurpose
                                    Step 1 UCS-A# scope system  

                                    Enters system mode.

                                     
                                    Step 2 UCS-A /system # delete scheduler sched-name  

                                    Deletes a scheduler and enters scheduler mode.

                                     
                                    Step 3 UCS-A /system # commit-buffer  

                                    Commits the transaction to the system configuration.

                                     

                                    The following example deletes a scheduler called maintenancesched and commits the transaction:

                                    UCS-A# scope system
UCS-A /system # delete scheduler maintenancesched
UCS-A /system* # commit-buffer
UCS-A /system #

                                    Configuring Maintenance Policies

                                    Creating a Maintenance Policy

                                    Before You Begin

                                    If you plan to configure this maintenance policy for deferred deployment, create a schedule.

                                    Procedure
                                       Command or ActionPurpose
                                      Step 1UCS-A# scope org org-name  

                                      Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .

                                       
                                      Step 2UCS-A /org # create maint-policy policy-name  

                                      Creates the specified maintenance policy and enters maintenance policy mode.

                                       
                                      Step 3UCS-A /org/maint-policy # set reboot-policy {immediate | timer-automatic | user-ack}  
                                      When a service profile is associated with a server, the server needs to be rebooted to complete the association. Specifying the reboot-policy command determines when the reboot occurs for all service profiles that include this maintenance policy. Possible values include:

                                      • immediate--The server reboots as soon as the change is made to the service profile.

                                      • timer-automatic --You select the schedule that specifies when maintenance operations can be applied to the server using the set scheduler command. Cisco UCS reboots the server and completes the service profile changes at the scheduled time.

                                      • user-ack --The user must explicitly acknowledge the changes by using the apply pending-changes command before changes are applied.

                                       
                                      Step 4UCS-A /org/maint-policy # set scheduler scheduler-name   (Optional)

                                      If the reboot-policy property is set to timer-automatic, you must select the schedule that specifies when maintenance operations can be applied to the server. Cisco UCS reboots the server and completes the service profile changes at the scheduled time.

                                       
                                      Step 5UCS-A /org/maint-policy # commit-buffer  

                                      Commits the transaction to the system configuration.

                                       
                                      The following example creates a maintenance policy called maintenance, sets the system to reboot immediately when a service profile is associated with a server, and commits the transaction:
                                      UCS-A# scope org /
UCS-A /org # create maint-policy maintenance
UCS-A /org/maint-policy* # set reboot-policy immediate
UCS-A /org/maint-policy* # commit-buffer
UCS-A /org/maint-policy #

                                      Deleting a Maintenance Policy

                                      Procedure
                                         Command or ActionPurpose
                                        Step 1UCS-A# scope org org-name  

                                        Enters organization mode for the specified organization. To enter the root organization mode, type / as the org-name .

                                         
                                        Step 2UCS-A /org # delete maint-policy policy-name  

                                        Deletes the specified maintenance policy.

                                         
                                        Step 3UCS-A /org # commit-buffer  

                                        Commits the transaction to the system configuration.

                                         
                                        The following example deletes a maintenance policy called maintenance and commits the transaction:
                                        UCS-A# scope org /
UCS-A /org # delete maint-policy maintenance
UCS-A /org/maint-policy* # commit-buffer
UCS-A /org/maint-policy #

                                        Managing Pending Activities

                                        Viewing Pending Activities

                                        Procedure
                                           Command or ActionPurpose
                                          Step 1 UCS-A# scope org org-name  

                                          Enters organization mode.

                                          To enter the root organization mode, type / as the org-name.

                                           
                                          Step 2 UCS-A /org # scope service-profile profile-name  

                                          Enters organization service profile mode for the specified service.

                                           
                                          Step 3 UCS-A /org/service-profile # show pending-changes [detail | expand]  

                                          Displays details about pending-changes.

                                           

                                          The following example shows how to display pending changes for a service profile called accounting:

                                          UCS-A# scope org /
UCS-A /org # scope service-profile accounting
UCS-A /org/service-profile # show pending-changes detail

Pending Changes:
    Scheduler:
    Changed by: admin
    Acked by:
    Mod. date: 2010-09-20T20:36:09.254
    State: Untriggered
    Admin State: Untriggered
    Pend. Changes: 0
    Pend. Disr.: 0
UCS-A /org/service-profile #

                                          Deploying a Service Profile Change Waiting for User Acknowledgement

                                          Cisco UCS Manager CLI cannot deploy all pending service profile changes (for multiple service profiles) waiting for user acknowledgement. To simultaneously deploy all pending service profile changes for multiple service profiles, use Cisco UCS Manager GUI.
                                          Important:

                                          You cannot stop Cisco UCS Manager from rebooting the affected server after you acknowledge a pending activity.

                                          Procedure
                                             Command or ActionPurpose
                                            Step 1 UCS-A# scope org org-name  

                                            Enters organization mode.

                                            To enter the root organization mode, type / as the org-name.

                                             
                                            Step 2 UCS-A /org # scope service-profile profile-name  

                                            Enters organization service profile mode for the specified service.

                                             
                                            Step 3 UCS-A /org/service-profile # apply pending-changes immediate  

                                            Applies the pending changes immediately.

                                            Cisco UCS Manager immediately reboots the server affected by the pending activity.

                                             

                                            The following example shows how to apply pending changes for a service profile called accounting:

                                            UCS-A# scope org /
UCS-A /org # scope service-profile accounting
UCS-A /org/service-profile # apply pending-changes immediate
UCS-A /org/service-profile #

                                            Deploying a Scheduled Service Profile Change Immediately

                                            Cisco UCS Manager CLI cannot deploy all scheduled service profile changes (for multiple service profiles) at the same time. To simultaneously deploy all scheduled service profile changes for multiple service profiles, use Cisco UCS Manager GUI.
                                            Important:

                                            You cannot stop Cisco UCS Manager from rebooting the affected server after you acknowledge a pending activity.

                                            Procedure
                                               Command or ActionPurpose
                                              Step 1 UCS-A# scope org org-name  

                                              Enters organization mode.

                                              To enter the root organization mode, type / as the org-name.

                                               
                                              Step 2 UCS-A /org # scope service-profile profile-name  

                                              Enters organization service profile mode for the specified service.

                                               
                                              Step 3 UCS-A /org/service-profile # apply pending-changes immediate  

                                              Applies the pending changes immediately.

                                              Cisco UCS Manager immediately reboots the server affected by the pending activity.

                                               

                                              The following example shows how to apply pending changes for a service profile called accounting:

                                              UCS-A# scope org /
UCS-A /org # scope service-profile accounting
UCS-A /org/service-profile # apply pending-changes immediate
UCS-A /org/service-profile #

                                              Was this Document Helpful?

                                              Feedback

                                              Let Us Help