Came here to say this. I was a grad student at U of T working with some of the original SnowFlock authors back in 2009. (Although I had no hand in the developme

Came here to say this. I was a grad student at U of T working with some of the original SnowFlock authors back in 2009. (Although I had no hand in the development of SnowFlock itself, I did contribute to some of the follow up work.) Skimming through the article, it looks like the high level idea is the same. The major difference seems to be that SnowFlock would start a proprietary server which is responsible for sending memory pages over the network on demand whenever the clone reads them. Some follow up work also added several different prefetching strategies to improve the performance of the cloned VMs while they were still fetching remote memory. SnowFlock was really targeted at compute-heavy applications. The idea was that you could mostly set up your application in the single VM, clone it, and then after cloning, it could be fairly easy to configure the clones to continue working on the problem in parallel. My Masters thesis made use of SnowFlock to clone relational databases on demand. https://www.researchgate.net/publication/221351958_FlurryDB_A_dynamically_scalable_relational_database_with_virtual_machine_cloning https://www.researchgate.net/publication/221351958_FlurryDB_...