Fill gaps from assistant conversations: network volume datacenter scope

pods/troubleshooting/pod-migration.mdx

@@ -1,7 +1,7 @@
 ---
 title: "Pod migration"
 description: "Automatically migrate your Pod to a new machine when your GPU is unavailable. Review setup, configuration, and operations guidance for Runpod Pods."
 tag: "BETA"
 ---
 
 import { MachineTooltip } from "/snippets/tooltips.jsx";
@@ -19,20 +19,24 @@
   allowFullScreen
 ></iframe>
 
 When you start a Pod, it's assigned to a specific physical <MachineTooltip /> with 4-8 GPUs. This creates a link between your Pod and that particular machine. As long as your Pod is running, that GPU is exclusively reserved for you, which ensures stable pricing and prevents your work from being interrupted.
 
 When you stop a Pod, you release that specific GPU, allowing other users to rent it. If another user rents the GPU while your Pod is stopped, the GPU will be occupied when you try to restart. Because your Pod is still tied to that original machine, you'll see message asking you to migrate your Pod. This doesn't mean there are no GPUs of that type available on Runpod, just that none are available on the specific physical machine where your Pod's data is stored.
 
 ## Your options when GPUs are unavailable
 
 When prompted to migrate your Pod, you have three options:
 
 1. **Do nothing**: If you don't want to migrate your data, you can wait and try again later. The GPU will become available once another user stops their Pod on that machine.
 
 2. **Start Pod with CPUs**: If you don't need GPU access immediately, you can start your Pod with CPUs only. This lets you access your data and manually migrate files if needed, but the Pod will have limited CPU resources and is not suitable for compute-intensive tasks.
 
 3. **Automatically migrate Pod data**: This option spins up a new Pod with the same specifications as your current one and automatically migrates your data to a machine with available GPUs. The migration process finds a new machine with your requested GPU type, provisions the instance, and transfers your network volume data from the old Pod to the new one.
 
+<Warning>
+Migration only searches for GPUs in the same datacenter as your [network volume](/storage/network-volumes). The volume can't be moved, so GPUs in other datacenters can't be used with it. If migration returns "no instances currently available" while the same GPU type appears in the general deploy list, those GPUs are in other datacenters. To resolve this, wait for capacity in your volume's datacenter, or create a new network volume in a different datacenter and copy your data over.
+</Warning>
+
 ## Important considerations for migration
 
 When you trigger an automatic Pod migration, you'll receive a new Pod with a new ID and IP address. This is because Pod IDs are architecturally tied to specific physical machines.
@@ -40,11 +44,11 @@
 This may impact your workload if you have:
 
 - A Pod ID hardcoded in an API call.
 - A proxy URL hardcoded (e.g., `http://b63b243b47bd340becc72fbe9b3e642c.proxy.runpod.net`).
 - A firewall or VPN configured with a specific Pod ID.
 - A firewall or VPN configured with a specific Pod IP address.
 - A specific URL for your server (when you start a new Pod, you'll get a new URL for any UI or server you've set up).
 
 ## Preventing Pod migration scenarios
 
 The most effective way to avoid the need for Pod migrations is to use [network volumes](/storage/network-volumes). Network volumes decouple your data from specific physical machines, storing your `/workspace` data on a separate, persistent volume that can be attached to any Pod. If you need to terminate a Pod, you can deploy a new one and attach the same network volume, giving you immediate access to your data on any machine with an available GPU.

storage/network-volumes.mdx

@@ -1,20 +1,24 @@
 ---
 title: "Network volumes"
 description: "Persistent, portable storage for your AI workloads. Review configuration, access methods, and usage guidance for managing storage on Runpod."
 ---
 
 import { PodsTooltip, ServerlessTooltip, WorkersTooltip, ColdStartTooltip, InstantClusterTooltip } from "/snippets/tooltips.jsx";
 
 Network volumes provide persistent storage that exists independently of your compute resources. Data is retained when <PodsTooltip /> terminate or <ServerlessTooltip /> <WorkersTooltip /> scale to zero. Use them to share data across multiple machines and Runpod products.
 
 Network volumes are backed by high-performance NVMe SSDs with transfer speeds of 200-400 MB/s (up to 10 GB/s peak).
 
+<Note>
+Each network volume lives in a single datacenter and cannot be moved. Any Pod, worker, or Instant Cluster that attaches the volume must run in that same datacenter. This limits the GPU inventory available to those workloads. To spread across datacenters, create a separate volume in each one and copy data between them manually. See [Migrate files between volumes](#migrate-files-between-volumes).
+</Note>
+
 ## Storage tiers
 
 Network volumes are available in two tiers:
 
 - **Standard storage**: Cost-effective storage for general-purpose work, development, and workloads where storage isn't the bottleneck.
 - **[High-performance storage](/storage/high-performance-storage)**: Premium tier with up to 3x throughput and 4x IOPS, optimized for training, fine-tuning, and latency-sensitive inference.
 
 Select the storage tier when creating a network volume. For details on choosing between tiers, see [High-performance storage](/storage/high-performance-storage).
 
@@ -24,7 +28,7 @@
 - **First 1 TB**: \$0.07/GB/month
 - **Beyond 1 TB**: \$0.05/GB/month
 
 **High-performance storage** is priced at a premium. See the [High-performance storage](/storage/high-performance-storage#pricing) page for details.
 
 <Warning>
 When your account balance reaches \$0, Pods with an attached network volume are stopped and your data is preserved on the volume. Storage charges continue to accrue while the Pod is stopped, so if your balance stays at \$0 and these charges can't be covered, the network volume may eventually be terminated and its data cannot be recovered. Enable [low balance notifications](/accounts-billing/billing#low-balance-notifications) to get alerted before this happens.
@@ -61,9 +65,9 @@
   </Tab>
 </Tabs>
 
 ## Network volumes for Serverless
 
 Network volumes mount at `/runpod-volume` within Serverless workers. Benefits include reduced <ColdStartTooltip /> times (no re-downloading models), lower costs, and centralized data management.
 
 **Attach to an endpoint:**
 
@@ -80,7 +84,7 @@
 
 Attaching a single network volume constrains worker deployments to that volume's datacenter, which may limit GPU availability and reduce failover options.
 
 To improve availability and reduce downtime during datacenter maintenance, attach multiple network volumes from different datacenters. Workers are distributed across these datacenters, with each worker receiving exactly one volume based on its assigned location.
 
 <Note>
 You can only select one network volume per datacenter.
@@ -90,7 +94,7 @@
 **Data does not sync automatically between volumes.** To make the same data available to all workers regardless of datacenter, manually copy data using the [S3-compatible API](/storage/s3-api) or [runpodctl](#using-runpodctl).
 </Warning>
 
 ## Network volumes for Pods
 
 Network volumes replace the Pod's default volume disk, typically mounted at `/workspace`.
 
@@ -102,14 +106,14 @@
 
 1. Navigate to [Pods](https://www.console.runpod.io/pods) and click **Deploy**.
 2. Select **Network Volume** and choose your volume.
 3. Select a GPU type (available options depend on volume location).
 4. Configure template and other settings, then click **Deploy On-Demand**.
 
 Network volumes must be attached during Pod deployment. They cannot be attached or detached later without deleting the Pod.
 
 ## Network volumes for Instant Clusters
 
 Network volumes for <InstantClusterTooltip />s work like Pods. Attach during cluster creation; mounts at `/workspace` on each node.
 
 1. Go to [Instant Clusters](https://www.console.runpod.io/cluster) and click **Create Cluster**.
 2. Click **Network Volume** and select the volume to attach.
@@ -124,7 +128,7 @@
 
 ### Using runpodctl
 
 The simplest way to migrate files between network volumes is to use `runpodctl send` and `receive` on two running Pods:
 
 <Steps>
   <Step title="Deploy two Pods">
@@ -147,7 +151,7 @@
   </Step>
 </Steps>
 
 ### Using rsync over SSH
 
 For faster migration speed and more reliability for large transfers, you can use `rsync` over SSH on two running Pods: