Los recursos físicos mantienen siempre su posición y, por tanto, no son móviles. No obstante, hay dos casos que aparecen al considerar un DAMN que requieren de ciertas técnicas relacionadas con la ``movilidad de recursos'':
En ambos casos el sistema debe hacer frente a cambios en la posición de recursos del sistema. Elementos físicos--p.ej. bancos de memoria--que contienen unidades elementales de recursos--p.ej. marcos de página--, en el primer caso; abstracciones del sistema--p.ej. Portales en Off-- en el segundo caso.
Como ya se describió anteriormente, Off utiliza identificadores que ayudan a localizar recursos que son susceptibles de cambios de posición. De este modo, con ayuda del estado exportado por el kernel, es posible tolerar el cambio de posición de dichos recursos. Por ejemplo, podemos capturar el estado de un recurso determinado y emplear dicho estado con posterioridad para ``recrearlo'' en una ubicación distinta; el identificador de dicho recurso seguirá siendo válido.
En el caso de movimiento de elementos físicos, al estar estos identificados con el portal del gestor, basta cambiar el manejador de dicho portal para que el gestor del elemento opere en la nueva posición. Los nombres de las unidades elementales contenidas en el elemento mantienen su validez al ser relativos al identificador del gestor.
A modo de ejemplo, los nombres de los marcos de página de un banco de memoria siguen siendo válidos si el banco de memoria se reemplaza por otro en un nodo distinto: los marcos están nombrados por identificadores p:o, donde p identifica el banco de memoria y por tanto es el portal del gestor de dicho banco de memoria (ver apartado 2.1.2). Si el banco cambia de nodo, pero el gestor mantiene el portal p, las peticiones destinadas hacia los marcos seguirán funcionando correctamente. Los marcos se pueden replicar en el nodo destino (antes de desmantelar el banco de memoria origen) dado que el kernel no oculta ni el estado ni el contenido de los marcos. Alguien con privilegios suficientes puede sencillamente leer dicho estado (qué marcos están asignados, a quién, etc.) y replicarlo en el banco de memoria destino. Para replicarlo basta con copiar la memoria que lo contiene, no es preciso hacer traducción alguna puesto que los identificadores (referencias) contenidas en dicho estado tienen validez en todo el sistema distribuido.
El caso más delicado es el movimiento de abstracciones y consiguientemente lo trataremos en más detalle. En el caso de portales, shuttles y DTLBs sus identificadores están diseñados para facilitar su cambio de posición. Concretamente, dos de los tres componentes de los identificadores se emplean en la localización de los objetos nombrados con ellos:
En realidad, podemos pensar en la parte privada de los identificadores como en información privada del implementador del objeto que viaja junto con el nombre del mismo. Esta información puede utilizarse del mismo modo que se utilizan tablas hash en otros sistemas para localizar la implementación de un objeto a partir de su identificador [167, 2].
Para comprender mejor lo expuesto anteriormente, consideremos lo que ocurre cuando se crea un portal y también qué sucede cuando dicho portal se mueve de un nodo a otro.
Al crearse el portal se construye su identificador. El campo de nodo y secuencia se asignan de tal modo que el primero refleje el nodo donde se creó dicho portal y que ambos sean únicos (conjuntamente) a todo lo largo de la vida del sistema. El servidor de portales (el implementador de los portales) ha de asignar una estructura de datos nueva para mantener los datos del portal creado. Las estructuras de datos o descriptores de portales están situadas en un vector dentro del servidor de portales. Como puede suponerse en este punto, el índice en dicho vector para el portal creado se almacena en slot dentro del identificador de dicho portal.
Cuando un usuario del sistema referencia el portal, el servidor de portales extrae slot del identificador e indexa en su vector de portales para obtener el descriptor. Si el portal no ha migrado se ha localizado con una sóla indexación. No ha sido preciso el empleo de tablas hash, estructuras arborescentes u otro mecanismo más costoso.
Supongamos ahora que dicho portal cambia su posición. Cualquier
cliente de dicho portal enviará una petición (como hacía siempre) al
nodo de creación del mismo. Ahora bien, el servidor de portales de
dicho nodo indexará (utilizando de nuevo el campo slot) en su
vector de portales y encontrará o una entrada libre, o un portal
distinto
(los campos nodo y secuencia
serán distintos).
En este punto se eleva una excepción que deberá tratar la aplicación. El propósito de dicha excepción es permitir a distintas aplicaciones el uso de distintos protocolos de localización. Aquellas aplicaciones que lo deseen, pueden hacer que un servidor--implementando un protocolo de localización de propósito general--trate esta excepción.
El manejador de la excepción localiza el portal (como veremos más adelante) y notifica al cliente de la nueva localización (en efecto, hace cache del nombre). De aquí en adelante el cliente enviará cualquier futura petición al nodo adecuado. Dado que el identificador de un portal es en realidad el valor de su parte pública (campos nodo y secuencia), en la notificación de relocalización recibida puede recibirse un nuevo valor para el campo slot del nombre del portal.
En pocas palabras, sólo la primera llamada a un portal tras la
migración del mismo ocasiona más trabajo que una invocación antes de
dicha migración. Posteriores llamadas presentan el mismo coste en
tiempo que para aquellos portales que no han cambiado de posición. Es
de reseñar que el 
kernel no incorpora ningún protocolo concreto y tan
sólo mantiene la última localización conocida, de este modo diferentes
aplicaciones pueden optar por diversos esquemas a la hora de tolerar
migración de recursos.
Nótese que la libertad en la implementación del protocolo de localización es casi absoluta. En aquellas ocasiones donde las migraciones son predecibles (p.ej. si se definen en tiempo de compilación) el protocolo de localización puede ser una búsqueda en una tabla. En redes de área local se pueden emplear algoritmos que aprovechen facilidades de difusión (broadcast), si las hay. También es posible implementar cualquier estructura de cache jerárquica de ubicaciones que sea imaginable para evitar ejecuciones del algoritmo de localización.
Para permitir la implementación de estos protocolos de localización,
el kernel permite la lectura de la memoria que contiene el vector de
portales directamente desde nivel de usuario.
Por último, hay que tener presente que los usuarios realizan peticiones al servidor de portales de su nodo (de forma transparente), siendo éste el que se encarga de reenviar la petición (si procede, y mediante protocolos suministrados por las aplicaciones) al nodo apropiado de acuerdo con la información presente en la parte pública del identificador de portal.
Hablaremos más de la movilidad de recursos abstractos del sistema en el apartado 2.4.