You linked to the migration of a single operating system kernel. That is very different from reproducing the running state of an entire distributed system. Migrating a single kernel is not easy, but straight-forward: you have access to all of the relevant pieces (in memory process state, and state on disks) in one place. With a distributed system, that is not so, since the the running state of a distributed system will include information in-flight, some of which is not virtualized.

It is possible to migrate the state of a distributed system by designing a protocol such that all of the components stop sending information around, so that you can be sure you did not miss anything. But I think that violates the spirit of the phrase "running state", since you essentially stopped the system. It's also not necessarily so that post-migration, the system will act the same.

You might be interested in the Chandy-Lamport snapshot algorithm, which can do what you describe without stopping the system's execution.

I'm aware of such things, and in fact I work on a system that supports something very similar. (Paper to be published by my colleagues in the industry track of VLDB.) But that is a logical snapshot. Through a clever protocol, and assuming some characteristics of your transport, you can save a state across your system that is logically consistent. That is, if you restored to this logical state, the distributed application can resume from that point, and maintain integrity. You may, however, lose information from your system that was computed after you took your snapshot. The state is logically consistent, but unlikely to be representative of any actual point in time.

Strictly speaking you're correct -- a distributed snapshot doesn't capture the state of the system at a single instant. But there's a sense in which the nondeterminism introduced by the snapshot is no worse than the nondeterminism that is intrinsic to a distributed system.

To be more precise: any "possible outcome" of the snapshot was also possible at some point during the original execution. And likewise, any "impossible outcome" of the snapshot was also ruled out at some point in the original. So if viewed from the outside, the fact that you took and restored a snapshot is indistinguishable from the normal situation of having an asynchronous network. It can't cause the system to exhibit any behaviors that weren't otherwise allowable.

(Apologies if I'm just restating what you already know; other readers may not be aware of it. This might be the same property that you're calling "integrity".)

This is reminiscent of one of Scott Aaronson's comments from the original article. If quantum effects are significant in the brain, then it's impossible -- even in principle -- to "perfectly" copy it such that the original and the copy are guaranteed to behave identically. But if the original and the copy are statistically indistinguishable, it amounts to the same thing.

So, basically the same reasons why I'd never step into a teleporter :)

Why would you need to copy the entire running state of the distributed system?

> distributed

And even the Xen example is rough; the new copy of the system will be mostly functionally identical, but any reliance on the state of external things (like remote storage or IO or the state of unfair nondeterministic locks) will rapidly cause state to diverge.

Which only begs the question about how high-fidelity a copy has to be to be a "copy", even in the case of a hypothetical consciousness copy, and leads into the even more subtle question of the time evolution of a person and whether the me of now and the me of twenty seconds ago can be said to represent the same singular "consciousness" at all.

This puts a fun spin on the teleportation/cloning thought experiment.

What do you think all the shimmery stuff on the Star Trek TOS transporter was?