---
title: "Lists the Compute Nodes in the specified Pool."
method: GET
path: "/pools/{poolId}/nodes"
tags: ["ComputeNodes"]
---

# Lists the Compute Nodes in the specified Pool.

`GET /pools/{poolId}/nodes`

## Path parameters

- `poolId` string, required

## Query parameters

- `$filter` string
- `$select` string
- `maxresults` integer
- `timeout` integer
- `api-version` string, required

## Headers

- `client-request-id` string, uuid
- `return-client-request-id` boolean
- `ocp-date` string, date-time-rfc1123

## Response `200`

A response containing the list of Compute Nodes.

- ComputeNodeListResult
  - `value` ComputeNode[]
    - `id` string — Every Compute Node that is added to a Pool is assigned a unique ID. Whenever a Compute Node is removed from a Pool, all of its local files are deleted, and the ID is reclaimed and could be reused for new Compute Nodes.
    - `url` string
    - `state` 'idle' | 'rebooting' | 'reimaging' | 'running' | 'unusable' | 'creating' | 'starting' | 'waitingforstarttask' | 'starttaskfailed' | 'unknown' | 'leavingpool' | 'offline' | 'preempted' — The low-priority Compute Node has been preempted. Tasks which were running on the Compute Node when it was preempted will be rescheduled when another Compute Node becomes available.
    - `schedulingState` 'enabled' | 'disabled'
    - `stateTransitionTime` string, date-time
    - `lastBootTime` string, date-time — This property may not be present if the Compute Node state is unusable.
    - `allocationTime` string, date-time — This is the time when the Compute Node was initially allocated and doesn't change once set. It is not updated when the Compute Node is service healed or preempted.
    - `ipAddress` string — Every Compute Node that is added to a Pool is assigned a unique IP address. Whenever a Compute Node is removed from a Pool, all of its local files are deleted, and the IP address is reclaimed and could be reused for new Compute Nodes.
    - `affinityId` string — Note that this is just a soft affinity. If the target Compute Node is busy or unavailable at the time the Task is scheduled, then the Task will be scheduled elsewhere.
    - `vmSize` string — For information about available sizes of virtual machines in Pools, see Choose a VM size for Compute Nodes in an Azure Batch Pool (https://docs.microsoft.com/azure/batch/batch-pool-vm-sizes).
    - `totalTasksRun` integer
    - `runningTasksCount` integer
    - `totalTasksSucceeded` integer
    - `recentTasks` TaskInformation[] — This property is present only if at least one Task has run on this Compute Node since it was assigned to the Pool.
      - `taskUrl` string
      - `jobId` string
      - `taskId` string
      - `subtaskId` integer
      - `taskState` 'active' | 'preparing' | 'running' | 'completed', required
      - `executionInfo` TaskExecutionInformation
        - `startTime` string, date-time — 'Running' corresponds to the running state, so if the Task specifies resource files or Packages, then the start time reflects the time at which the Task started downloading or deploying these. If the Task has been restarted or retried, this is the most recent time at which the Task started running. This property is present only for Tasks that are in the running or completed state.
        - `endTime` string, date-time — This property is set only if the Task is in the Completed state.
        - `exitCode` integer — This property is set only if the Task is in the completed state. In general, the exit code for a process reflects the specific convention implemented by the application developer for that process. If you use the exit code value to make decisions in your code, be sure that you know the exit code convention used by the application process. However, if the Batch service terminates the Task (due to timeout, or user termination via the API) you may see an operating system-defined exit code.
        - `containerInfo` TaskContainerExecutionInformation
          - `containerId` string
          - `state` string — This is the state of the container according to the Docker service. It is equivalent to the status field returned by "docker inspect".
          - `error` string — This is the detailed error string from the Docker service, if available. It is equivalent to the error field returned by "docker inspect".
        - `failureInfo` TaskFailureInformation
          - `category` 'usererror' | 'servererror', required
          - `code` string
          - `message` string
          - `details` NameValuePair[]
            - `name` string
            - `value` string
        - `retryCount` integer, required — Task application failures (non-zero exit code) are retried, pre-processing errors (the Task could not be run) and file upload errors are not retried. The Batch service will retry the Task up to the limit specified by the constraints.
        - `lastRetryTime` string, date-time — This element is present only if the Task was retried (i.e. retryCount is nonzero). If present, this is typically the same as startTime, but may be different if the Task has been restarted for reasons other than retry; for example, if the Compute Node was rebooted during a retry, then the startTime is updated but the lastRetryTime is not.
        - `requeueCount` integer, required — When the user removes Compute Nodes from a Pool (by resizing/shrinking the pool) or when the Job is being disabled, the user can specify that running Tasks on the Compute Nodes be requeued for execution. This count tracks how many times the Task has been requeued for these reasons.
        - `lastRequeueTime` string, date-time — This property is set only if the requeueCount is nonzero.
        - `result` 'success' | 'failure'
    - `startTask` StartTask — Batch will retry Tasks when a recovery operation is triggered on a Node. Examples of recovery operations include (but are not limited to) when an unhealthy Node is rebooted or a Compute Node disappeared due to host failure. Retries due to recovery operations are independent of and are not counted against the maxTaskRetryCount. Even if the maxTaskRetryCount is 0, an internal retry due to a recovery operation may occur. Because of this, all Tasks should be idempotent. This means Tasks need to tolerate being interrupted and restarted without causing any corruption or duplicate data. The best practice for long running Tasks is to use some form of checkpointing. In some cases the StartTask may be re-run even though the Compute Node was not rebooted. Special care should be taken to avoid StartTasks which create breakaway process or install/launch services from the StartTask working directory, as this will block Batch from being able to re-run the StartTask.
      - `commandLine` string, required — The command line does not run under a shell, and therefore cannot take advantage of shell features such as environment variable expansion. If you want to take advantage of such features, you should invoke the shell in the command line, for example using "cmd /c MyCommand" in Windows or "/bin/sh -c MyCommand" in Linux. If the command line refers to file paths, it should use a relative path (relative to the Task working directory), or use the Batch provided environment variable (https://docs.microsoft.com/en-us/azure/batch/batch-compute-node-environment-variables).
      - `containerSettings` TaskContainerSettings
        - `containerRunOptions` string — These additional options are supplied as arguments to the "docker create" command, in addition to those controlled by the Batch Service.
        - `imageName` string, required — This is the full Image reference, as would be specified to "docker pull". If no tag is provided as part of the Image name, the tag ":latest" is used as a default.
        - `registry` ContainerRegistry
          - `registryServer` string — If omitted, the default is "docker.io".
          - `username` string, required
          - `password` string, required
        - `workingDirectory` 'taskWorkingDirectory' | 'containerImageDefault' — The default is 'taskWorkingDirectory'.
      - `resourceFiles` ResourceFile[] — Files listed under this element are located in the Task's working directory.
        - `autoStorageContainerName` string — The autoStorageContainerName, storageContainerUrl and httpUrl properties are mutually exclusive and one of them must be specified.
        - `storageContainerUrl` string — The autoStorageContainerName, storageContainerUrl and httpUrl properties are mutually exclusive and one of them must be specified. This URL must be readable and listable using anonymous access; that is, the Batch service does not present any credentials when downloading blobs from the container. There are two ways to get such a URL for a container in Azure storage: include a Shared Access Signature (SAS) granting read and list permissions on the container, or set the ACL for the container to allow public access.
        - `httpUrl` string — The autoStorageContainerName, storageContainerUrl and httpUrl properties are mutually exclusive and one of them must be specified. If the URL points to Azure Blob Storage, it must be readable using anonymous access; that is, the Batch service does not present any credentials when downloading the blob. There are two ways to get such a URL for a blob in Azure storage: include a Shared Access Signature (SAS) granting read permissions on the blob, or set the ACL for the blob or its container to allow public access.
        - `blobPrefix` string — The property is valid only when autoStorageContainerName or storageContainerUrl is used. This prefix can be a partial filename or a subdirectory. If a prefix is not specified, all the files in the container will be downloaded.
        - `filePath` string — If the httpUrl property is specified, the filePath is required and describes the path which the file will be downloaded to, including the filename. Otherwise, if the autoStorageContainerName or storageContainerUrl property is specified, filePath is optional and is the directory to download the files to. In the case where filePath is used as a directory, any directory structure already associated with the input data will be retained in full and appended to the specified filePath directory. The specified relative path cannot break out of the Task's working directory (for example by using '..').
        - `fileMode` string — This property applies only to files being downloaded to Linux Compute Nodes. It will be ignored if it is specified for a resourceFile which will be downloaded to a Windows Compute Node. If this property is not specified for a Linux Compute Node, then a default value of 0770 is applied to the file.
      - `environmentSettings` EnvironmentSetting[]
        - `name` string, required
        - `value` string
      - `userIdentity` UserIdentity — Specify either the userName or autoUser property, but not both.
        - `username` string — The userName and autoUser properties are mutually exclusive; you must specify one but not both.
        - `autoUser` AutoUserSpecification
          - `scope` 'task' | 'pool' — The default value is pool. If the pool is running Windows a value of Task should be specified if stricter isolation between tasks is required. For example, if the task mutates the registry in a way which could impact other tasks, or if certificates have been specified on the pool which should not be accessible by normal tasks but should be accessible by StartTasks.
          - `elevationLevel` 'nonadmin' | 'admin'
      - `maxTaskRetryCount` integer — The Batch service retries a Task if its exit code is nonzero. Note that this value specifically controls the number of retries. The Batch service will try the Task once, and may then retry up to this limit. For example, if the maximum retry count is 3, Batch tries the Task up to 4 times (one initial try and 3 retries). If the maximum retry count is 0, the Batch service does not retry the Task. If the maximum retry count is -1, the Batch service retries the Task without limit.
      - `waitForSuccess` boolean — If true and the StartTask fails on a Node, the Batch service retries the StartTask up to its maximum retry count (maxTaskRetryCount). If the Task has still not completed successfully after all retries, then the Batch service marks the Node unusable, and will not schedule Tasks to it. This condition can be detected via the Compute Node state and failure info details. If false, the Batch service will not wait for the StartTask to complete. In this case, other Tasks can start executing on the Compute Node while the StartTask is still running; and even if the StartTask fails, new Tasks will continue to be scheduled on the Compute Node. The default is true.
    - `startTaskInfo` StartTaskInformation
      - `state` 'running' | 'completed', required
      - `startTime` string, date-time, required — This value is reset every time the Task is restarted or retried (that is, this is the most recent time at which the StartTask started running).
      - `endTime` string, date-time — This is the end time of the most recent run of the StartTask, if that run has completed (even if that run failed and a retry is pending). This element is not present if the StartTask is currently running.
      - `exitCode` integer — This property is set only if the StartTask is in the completed state. In general, the exit code for a process reflects the specific convention implemented by the application developer for that process. If you use the exit code value to make decisions in your code, be sure that you know the exit code convention used by the application process. However, if the Batch service terminates the StartTask (due to timeout, or user termination via the API) you may see an operating system-defined exit code.
      - `containerInfo` TaskContainerExecutionInformation
        - `containerId` string
        - `state` string — This is the state of the container according to the Docker service. It is equivalent to the status field returned by "docker inspect".
        - `error` string — This is the detailed error string from the Docker service, if available. It is equivalent to the error field returned by "docker inspect".
      - `failureInfo` TaskFailureInformation
        - `category` 'usererror' | 'servererror', required
        - `code` string
        - `message` string
        - `details` NameValuePair[]
          - `name` string
          - `value` string
      - `retryCount` integer, required — Task application failures (non-zero exit code) are retried, pre-processing errors (the Task could not be run) and file upload errors are not retried. The Batch service will retry the Task up to the limit specified by the constraints.
      - `lastRetryTime` string, date-time — This element is present only if the Task was retried (i.e. retryCount is nonzero). If present, this is typically the same as startTime, but may be different if the Task has been restarted for reasons other than retry; for example, if the Compute Node was rebooted during a retry, then the startTime is updated but the lastRetryTime is not.
      - `result` 'success' | 'failure'
    - `certificateReferences` CertificateReference[] — For Windows Nodes, the Batch service installs the Certificates to the specified Certificate store and location. For Linux Compute Nodes, the Certificates are stored in a directory inside the Task working directory and an environment variable AZ_BATCH_CERTIFICATES_DIR is supplied to the Task to query for this location. For Certificates with visibility of 'remoteUser', a 'certs' directory is created in the user's home directory (e.g., /home/{user-name}/certs) and Certificates are placed in that directory.
      - `thumbprint` string, required
      - `thumbprintAlgorithm` string, required
      - `storeLocation` 'currentuser' | 'localmachine' — The default value is currentuser. This property is applicable only for Pools configured with Windows Compute Nodes (that is, created with cloudServiceConfiguration, or with virtualMachineConfiguration using a Windows Image reference). For Linux Compute Nodes, the Certificates are stored in a directory inside the Task working directory and an environment variable AZ_BATCH_CERTIFICATES_DIR is supplied to the Task to query for this location. For Certificates with visibility of 'remoteUser', a 'certs' directory is created in the user's home directory (e.g., /home/{user-name}/certs) and Certificates are placed in that directory.
      - `storeName` string — This property is applicable only for Pools configured with Windows Compute Nodes (that is, created with cloudServiceConfiguration, or with virtualMachineConfiguration using a Windows Image reference). Common store names include: My, Root, CA, Trust, Disallowed, TrustedPeople, TrustedPublisher, AuthRoot, AddressBook, but any custom store name can also be used. The default value is My.
      - `visibility` string[] — You can specify more than one visibility in this collection. The default is all Accounts.
    - `errors` ComputeNodeError[]
      - `code` string
      - `message` string
      - `errorDetails` NameValuePair[]
        - `name` string
        - `value` string
    - `isDedicated` boolean
    - `endpointConfiguration` ComputeNodeEndpointConfiguration
      - `inboundEndpoints` InboundEndpoint[], required
        - `name` string, required
        - `protocol` 'tcp' | 'udp', required
        - `publicIPAddress` string, required
        - `publicFQDN` string, required
        - `frontendPort` integer, required
        - `backendPort` integer, required
    - `nodeAgentInfo` NodeAgentInformation — The Batch Compute Node agent is a program that runs on each Compute Node in the Pool and provides Batch capability on the Compute Node.
      - `version` string, required — This version number can be checked against the Compute Node agent release notes located at https://github.com/Azure/Batch/blob/master/changelogs/nodeagent/CHANGELOG.md.
      - `lastUpdateTime` string, date-time, required — This is the most recent time that the Compute Node agent was updated to a new version.
  - `odata.nextLink` string

## Other responses

- `default` — The error from the Batch service.

---

[API](https://skmtc.net/azure/apis/batchservice.md) · [All operations](https://skmtc.net/azure/apis/batchservice/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/azure/batchservice/versions/4c9161203dbe/schema)
