* Open files, and the state thereof, must be preserved during the
suspend/migration; for migration the entire filesystem would probably
have to be or appear at least largely identical.
* Network connections are even harder to migrate, as they must be
either bounced off of some form of masquerading at their original host
and/or need to run some sort of protocol to tear them down and recreate
them later after the migration/resume completes.
* Processes using resources peculiar to the local machine (e.g. doom or
anything else running with MITSHM; svgalib apps; dosemu; X at all if
migrating across a slow link) shouldn't migrate.
* Many things won't be suitable for migration, then, in a distributed
semi-homogeneous UN*X environment, and many semi-portable apps will need
to be migratable only at certain points.
* The way Linux handles shared libraries, restoration of clean code
pages from disk, etc., leads one to believe that migrating or
suspend/resuming a process would only entail migrating/saving the dirty
pages, pcb/vm data, and resource states; if migration merits being done,
it can be done quickly.
-- The priests and the friars/Behold me in dread Because I still love you,/My love, and you're dead. ---Dead Can Dance, "I Am Stretched On Your Grave", based on King/S. O'Connor's rewrite of "The Unquiet Grave", trad. Irish folk.