Towards Synchronization of Live Virtual Machines among Mobile Devices

Motivation:

• People increasingly rely on mobile devices in their everyday lives, often multiple devices such as a smartphone and a tablet. The utility of these devices would improve if users could switch seamlessly from one device to another, in particular if they could continue using applications on the second device exactly where they left off on the first device, with both data and computation state preserved across the switch without apparent delay. For example, a user who starts watching a video on a smartphone may want to continue watching the video on the larger display provided by a tablet. But there are some limitations including per-application data synchronization, intermittent connectivity and so on.

Main points:

• Introduction of VMsync, a system for synchronizing the state of live virtual machines (VMs) among mobile devices. In the context of device switching, VMs encapsulate both data and computation state for a complete operating system and all its applications. Therefore, synchronizing VM state between mobile devices automatically synchronizes all application state. And there are several established techniques for migrating VM state between hardware hosts: live migration(transfers a VM image while the VM continues to run in the originating host, only suspending the VM for an imperceptible period while control is finally switched to the receiving host) and opportunistic replay(decreasing the amount of data transferred during VM migration in low-bandwidth environments).
• Preliminary design: shows a initial architecture of VMsync, made up of multiple host devices with virtualization support and a resource-rich server in the cloud, used a synchronization point between devices. It seeks to incrementally transfer changes in an active VM on one device to standby VMs on other devices, so as to maintain a consistent VM image and minimize switching latency. The VMsync architecture involves a daemon running outside the guest VM on the active device. This daemon inspects the memory and file-system state of the VM and sends recent changes to a server in the cloud. The server then forwards the changes to standby devices.
• The progress of initial design of VMsync, only one active VM will be running at any given point in time to ensure that VMs do not diverge. This active device will propagate changes of both memory and file system state to the synchronization server over the period of time in which the device is active. We consider this process a checkpoint. Every other VM, considered standby VMs, will be paused and periodically updated via the synchronization server if the device is online. Devices which are not connected to the network or have not been synchronized will be considered to be in a stale state and must be synchronized before a user can switch to that device. 
• Feasibility study: set up the experiment environment on the Android platform. And author choice devices which are specific standards. Measuring checkpoint sizes: the author uses four curves, each corresponding to a different checkpointing policy to evaluate different policy’s performance. They are Dirty Orig, Diff Orig, Dirty Prev and Diff Prev. Measuring the total bytes required for Sync: the author used four elements which are Final Diff, Final Dirty, Incr Diff and Incr Dirty to help give some indication of which policies would have higher or lower switch penalties. In all cases, the Final Diff and Final Dirty results remain constant (within a standard deviation of the work- load) across varying time intervals. And author performed a combined workload which added background music. In general, the system background application has minimal effect on the system state.

Trade-offs:

• The author just used virtual data transfers as a rough proxy of various costs incurred during VM synchronization: bandwidth, latency and energy. Actually, if we would the policy is more convincing that author needs to design real experiment with different conditions to get the real data.
• The experiment is on Android platform. But as we all know, the Android and the IOS system have different architecture and backend scheme. The VMsync maybe suitable for the Android platform, but it maybe would have reverse effect on IOS platform. The author needs to consider this situation.
• In the measuring the total bytes required for Sync part, the author should consider that in different policies, final and incremental, may incur significant time and space overhead. The measure of overheads is important because it would influence the result of performance.
• The paper presents preliminary design for VMsync and a feasibility study aimed at determining how much data would need to be transferred under different mobile workloads and synchronization policies. Transfer the difference of previous checkpoint will be feasible. Measure total bytes required for Sync shows the policy would be feasible. To sum up, the VMsync is a feasible approach.