Mobile Desktop Computing In Your Pocket Computer Science Essay

Published:

In today's world of commodity computers, computers are truly ubiquitous. Users make use of computers at home, school, work, and on the road. However, the current personal computer framework ties a user's data, applications and execution state to a single underlying machine. While a user has access to many different machines, such as at the office and at home, each machine may provide a different computing environment. These different computing environments can provide the user with differing sets of applications as well as variable access to the data a user needs to complete a task. As computers can be prone to failure, applications and data tied to any particular machine can be unexpectedly rendered unavailable. This reliability problem is exacerbated for laptops, which often operate in more hostile working environments and are more prone to being stolen or to fail given the complexity of these devices.

To address these problems, we will present DeskPod, a portable system that decouples a desktop computing environment from any single hardware device so that it can be stored and executed anywhere. DeskPod will leverage commodity pocket able storage devices, ranging from flash memory sticks with no moving parts that can hold 4 GB of data to portable hard disks, such as Apple's iPod, that can hold 60 GB and more of data. DeskPod will enable these devices to hold a user's entire computing environment including applications, data and execution state so that it can be check pointed to portable storage, carried around easily and restarted from the storage device on a completely different computer. Since all applications, data and execution state are stored on the portable storage device, DeskPod will not rely on any application resources or data stored on the host machine. This also will enables users to continue working even in the face of faulty components as they can simply move their DeskPod environment to another host machine, or create another copy on another storage device. DeskPod will also enable mobile users to obtain the same persistent, personalized desktop computing experience from any computer.

Lady using a tablet
Lady using a tablet

Professional

Essay Writers

Lady Using Tablet

Get your grade
or your money back

using our Essay Writing Service!

Essay Writing Service

DeskPod will operate by encapsulating a user's desktop computing session in a virtualized execution environment and storing all state associated with the session on the portable storage device. This will enable DeskPod to be easily backed up when it is plugged into a user's primary computer by replicating all recent changes to DeskPod's file system. If the device is lost, users can then simply replicate the file system onto a new device and continue their work. DeskPod virtualization will decouple the desktop applications from the underlying operating system environment by introducing a private virtual namespace that provides consistent, host-independent naming of system resources. DeskPod also virtualizes the display so that the desktop session can be scaled to different display resolutions that may be available as a user moves from one computer to another. This enables a desktop computing session to run in the same way on any host despite differences that may exist among different host operating system environments and display hardware. Furthermore, DeskPod virtualization will protect the underlying host from untrusted applications that a user may run as part of a regular desktop session. DeskPod will provide this functionality without modifying, recompiling or relinking any applications or the operating system kernel.

LITERATURE REVIEW:

DeskPod builds upon my previous work on WebPod [8, 10], which first introduced a virtualized computing environment stored on a portable storage device in the context of web applications. WebPod, a portable system that enhances the web browsing experience of mobile users by providing them with the same persistent, personalized web browsing session wherever they are located and on whatever computer they are using. WebPod allows an entire web session to be stored on a small portable storage device that can be easily carried on a key chain or in a user's pocket. Web- Pod is more than just a web browser as it stores everything necessary for web browsing, including all helper applications and plug-ins.

WebPod provides its functionality by virtualizing operating system and display resources, decoupling a web browsing session from the host on which it is currently running. Web-Pod virtualization works together with a checkpoint/restart mechanism to enable WebPod users to suspend their web browsing sessions, move around, and resume their respective sessions at a later time on any computer right where they left off. WebPod's ability to migrate web browser sessions between differently configured and administered computers provides improved end user mobility. WebPod is unique in its ability to provide a complete, persistent, and consistent web browser environment that is not limited to a single machine. WebPod raises a number of interesting research areas.

Lady using a tablet
Lady using a tablet

Comprehensive

Writing Services

Lady Using Tablet

Plagiarism-free
Always on Time

Marked to Standard

Order Now

WebPod focuses on improving web usage for mobile users, but the same principles could be applied to other application domains as well. WebPod leverages available portable storage technologies, but it would be worthwhile to consider what additional benefits might be possible by adding some processing capabilities on a portable device, such as enhancing user privacy and security on untrusted computers. Finally, as portable storage devices increase in capacity and ubiquity, the decoupling of storage from the computer may open new directions in how computers should be designed and how they will be used in the future.

DeskPod builds on WebPod and expands the utility of its architecture to support general desktop applications in addition to just web browsing. DeskPod and WebPod builds on the previous work of Zap [7], which introduced operating system virtualization to support transparent migration. The operating system virtualization and checkpoint-restart mechanisms used in DeskPod and WebPod also build on my previous work on PeaPod [11] and AutoPod [9] which consider migration across different kernel versions in the context of system security and maintenance, respectively.

The PeaPod system provides an operating system virtualization layer that enables secure isolation of legacy applications. The virtualization layer supports two key abstractions for encapsulating processes, pods (PrOcess Domains) and peas (Protection and Encapsulation Abstraction). Pods provide an easy-to-use lightweight virtual machine abstraction that can securely isolate individual applications without the need to run an operating system instance in the pod. Peas provide a fine-grain least privilege mechanism that can further isolate application components within pods. PeaPod's virtualization layer can isolate untrusted applications, preventing them from being used to attack the underlying host system or other applications even if they are compromised.

PeaPod secure isolation functionality is achieved without any changes to applications or operating system kernels. We have implemented PeaPod in a Linux prototype and demonstrated how peas and pods can be used to improve computer security and application availability for a range of applications, including e-mail delivery, web servers and databases, and desktop computing. Our results show that PeaPod's virtualization layer can provide easily configurable and secure environments that can run a wide range of desktop and server Linux applications in least privilege environments with low overhead.

Similarly the AutoPod system provides an operating system virtualization layer that decouples process execution from the underlying operating system, by running the process within a pod. Pods provide an easy-to-use lightweight virtual machine abstraction that can securely isolate individual applications without the need to run an operating system instance in the pod. Furthermore, Auto-Pod can be transparently migrate isolated applications across machines running different operating system kernel versions. This enables security patches to be applied to operating systems in a timely manner with minimal impact on the availability of application services. It also preserves secure isolation of untrusted applications in the presence of migration.

The display virtualization mechanism used in DeskPod builds on the previous work of one of the authors on THINC [1]. THINC is a new virtual display system for high-performance thin-client computing built around a virtual device driver model. THINC introduces novel translation optimizations that take advantage of semantic information to efficient convert high-level application requests to a simple low-level protocol command set. THINC leverages client hardware capabilities to provide native support for audio/video playback, and supports small screen devices with server-side scaling of display updates. THINC's virtual display approach enables it to leverage continuing advances in window server technology and work seamlessly with unmodified applications, window systems, and operating systems.

Environments such as U3 [14] and Ceedo [3] are attempts to create a general application framework for applications to use to run on USB drives. While this enables a user to carry one's data and applications with them, it does not provide DeskPod's ability to carry the application state a well. Unlike U3, Ceedo does not require applications to be rewritten. However, it only virtualizes access to the Windows registry, thereby allowing applications to store data on the USB disk by default, but also enabling the applications to have full access to the underlying host machine.

Other approaches such as portable virtual appliances [4] and SoulPad [5] have used virtual machine monitors (VMMs) together with portable storage to provide a solution similar to DeskPod. Since these approaches are based on VMMs, they inherently tie processes to a complete operating system instance which can be more complex to manage than DeskPod. Furthermore, these approaches require taking over the entire host computer. For example, SoulPad has orders of magnitude higher startup latency because of the need to startup SoulPad's host operating system.

Lady using a tablet
Lady using a tablet

This Essay is

a Student's Work

Lady Using Tablet

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

Examples of our work

Thin-client systems [1, 2, 12] provide an attractive alter- native usage model that also provides many of the benefits of DeskPod. Unlike DeskPod which is self-contained and runs locally on the host where the user is currently located, thin clients require network access to additional server infrastructure.

PROBLEM DEFINATION:

In today's world of commodity computers, computers are truly ubiquitous. Users make use of computers at home, school, work, and on the road. However, the current personal computer framework ties a user's data, applications and execution state to a single underlying machine. While a user has access to many different machines, such as at the office and at home, each machine may provide a different computing environment. These different computing environments can provide the user with differing sets of applications as well as variable access to the data a user needs to complete a task. As computers can be prone to failure, applications and data tied to any particular machine can be unexpectedly rendered unavailable. This reliability problem is exacerbated for laptops, which often operate in more hostile working environments and are more prone to being stolen or to fail given the complexity of these devices.

Another problem that mobile users encounter is that they lack a common environment as they move around. The computer at the office is configured differently from the computer at home, which is different from the computer at the library. These locations can have different sets of software installed, which can make it difficult for a user to complete a task as the necessary software might not be available. Similarly, mobile users want consistent access to their files, which is difficult to guarantee as they move around.

METHODOLOGY:

To address these problems, we will present DeskPod, a portable system that decouples a desktop computing environment from any single hardware device so that it can be stored and executed anywhere. DeskPod will be a simple end user device that users can carry in their pockets. To the user, a DeskPod session will not appear to be any different from a private computer even though it runs on a host that may be running other applications. Those applications running outside of the DeskPod session will not visible to a user within a DeskPod session. To provide strong security, the DeskPod will store the session on an encrypted file system. Therefore, even if the DeskPod device is lost or stolen, an attacker will not have any access to the data stored on it.

A user will start DeskPod by plugging in a DeskPod portable storage device into the computer. The computer will detect the device and automatically tries to restart the DeskPod session. DeskPod will mount its encrypted file system, restarts its desktop computing session, and attaches a DeskPod viewer to the session to make the DeskPod session and its applications available and visible to the user. Applications running in a DeskPod session will appear to the underlying operating system just like other applications that are executing, and therefore they make use of the host's network interface in a normal manner.

Once DeskPod is started, a user can continue to use their applications, data and the saved execution state. When the user wants to leave the computer, the user simply closes the Desk Pod viewer. This will cause the DeskPod session to be quickly checkpointed to the DeskPod storage device, which can then be unplugged and carried around by the user. Since DeskPod saves and restores the execution state, there is no need for a user to manually launch the applications and reload documents. DeskPod's checkpoint/restart functionality will maintain a user's desktop computing session persistently as a user moves from one computer to another, even including ephemeral state such as copy/paste buffers. If the host machine used for DeskPod crashes, this will take down the current Desk Pod session with it. However, since DeskPod will not be having its own operating system, it can be simply plugged into a new host machine and to start a fresh DeskPod session. Similar to a regular computer, only data that was not committed to disk when the host machine crashed is lost.

DeskPod will only provide a desktop computing environment, not an entire operating system environment. DeskPod will make use of the operating system environment available on the host computer into which it is plugged in. This will provide two important benefits in terms of startup speed and management complexity. Since there will be no operating system on the DeskPod device, there is no need to boot or configure a new operating system environment to use DeskPod. Since only DeskPod applications need to be restarted, this will minimize startup costs for using DeskPod and ensures that DeskPod can be used on any machine on which a compatible operating system is running. Furthermore, there won't be any need for DeskPod users to maintain and manage an operating system environment, reducing management complexity thereby increasing reliability.

DeskPod will also protect desktop computing sessions by isolating each session in its own private execution environment. Other user-level applications running on the same machine are not able to access any state associated with a DeskPod session, protecting the privacy of a DeskPod user. Deskpod will rely on the host hardware and operating system kernel, as is common practice for users today. As a result, it will not protect users from attacks that may arise from tampered hardware or a compromised operating system kernel.

DeskPod will also provide a consistent usage environment that is compatible with the regular desktop computing model. Because DeskPod is small and travels with the user, there will be a risk of loss of the device and its associated data. DeskPod state will be encrypted on the storage device to minimize the damage suffered if the device is lost or stolen. To reduce the risk of data loss further, DeskPod will be backed up periodically when it returns to the user's own computer, in the same manner as a user synchronizes a PDA. If the DeskPod device is lost, the user's desktop computing session can be easily restored from backup onto another device.

DeskPod will virtualize the underlying host operating system and display to decouple DeskPod desktop computing sessions from the underlying host used for execution. This is essential to allow DeskPod applications to be isolated from the underlying system and other applications, to be checkpointed on one machine and restarted on another, and to be displayed on hosts with different display hardware and display resolution. Given the large existing base of desk- top applications and commodity operating systems, DeskPod virtualization will be designed to be completely transparent to work with existing unmodified applications and operating system kernels.

Operating System Virtualization

Operating system virtualization is necessary to ensure that operating system resource identifiers, such as process IDs (PIDs), remain constant throughout the life of a process to ensure its correct operation. Applications commonly manipulate these operating system resource identifiers as they execute. However, these identifiers are only unique to a particular operating system instance. When an application and its associated processes are moved from one computer to another, there is no guarantee that the destination operating system can provide the same identifiers to the migrated process. Those identifiers may already be in use by other processes running on the destination system, preventing the migrated process from executing correctly.

DeskPod will virtualize the underlying host operating system by encapsulating desktop computing sessions within a host independent, virtualized view of the operating system. DeskPod virtualization will provide each desktop computing session with its own virtual private namespace. For example, a DeskPod session will contain its own host independent view of operating system resources, such as PID/GID, IPC, memory, file system, and devices. The namespace will be the only means for the processes associated with running DeskPod application instances to access the underlying operating system. DeskPod will introduce this namespace to decouple processes associated with applications running in DeskPod sessions from the underlying host operating system.

The namespace will be private for the processes running within the session and they can see these namespaces, and the namespace in turn masks out resources that are not contained in the session. Processes inside the session will appear to one another as normal processes, and they will be able to communicate using traditional Inter-Process Communication (IPC) mechanisms. On the other hand, there won't any IPC interaction possible across the session's boundary, because outside processes on the DeskPod host are not part of the private namespace.

The DeskPod namespace will enable DeskPod processes to be isolated from the host system, checkpointed to its storage device, and transparently restarted on another machine. The private virtual namespace will provide consistent, virtual resource names for DeskPod processes enabling DeskPod sessions to migrate from one machine to another. Names within a session will be assigned in a unique manner in the same way that traditional operating systems assign names, but such names will be localized to the session. Since the namespace will be virtual, there is no need for it to change when the session is migrated, ensuring that identifiers remain constant throughout the life of the process, as required by applications that use such identifiers.

DeskPod will virtualize the operating system instance by using mechanisms that translate between the session's virtual resource identifiers and the operating system resource identifiers. For every resource accessed by a process in a session, the virtualization layer will associate a virtual name to an appropriate operating system physical name. When an operating system resource is created for a process in a session, the physical name returned by the system will be caught, and a corresponding private virtual name will be created and returned to the process. Similarly, any time a process passes a virtual name to the operating system, the virtualization layer catches and replaces it with the corresponding physical name. The key virtualization mechanisms that will be used are a system call interposition mechanism and the chroot utility with file system stacking for file system resources.

DeskPod virtualization will use system call interposition to virtualize operating system resources, including process identifiers, keys and identifiers for IPC mechanisms such as semaphores, shared memory, and message queues, and network addresses. System call interposition will wraps existing system calls to check and replace arguments that take virtual names with the corresponding physical names, before calling the original system call. Similarly, wrappers will be used to capture physical name identifiers that the original system calls return, and return corresponding virtual names to the calling process running inside the session. Session virtual names will be maintained consistently as a session migrates from one machine to another and are remapped appropriately to underlying physical names that may change as a result of migration. Session system call interposition will also masks out processes inside of a session from processes outside of the session to prevent any interprocess host de- pendencies across the session boundary.

DeskPod virtualization will employ the chroot utility and file systems stacking to provide each session with its own file system namespace. The DeskPod session's file sytem will be totally contained within its portable storage device, which guarantees that the same files can be made consistently available as the session is migrated from one computer to another. More specifically, when a DeskPod session is created or restarted on a host, a private directory will be created in the host. This directory serves as a staging area for the session's virtual file system. Within the directory, the session's file system will be mounted from the device. The chroot system call is then used to set the staging area as the root directory for the session, thereby achieving file system virtualization with negligible performance overhead. This method of file system virtualization will provide an easy way to restrict access to files and devices from within a session. This can be done by simply not including file hierarchies and devices within the session's file system namespace. If files and devices are not mounted within the session's virtual file system, they are not accessible to the session's processes.

File system virtualization must address the fact that there are multiples ways to break out of a chrooted environment, especially when the chroot system call is allowed to be used. The primary way DeskPod provides security will be by disallowing the privileged root user from being used within the session. The DeskPod session's file system virtualization will also enforce the chrooted environment and ensures that the session's file system will be the only files accessible to processes within session, by using a simple form of file system stacking to implement a barrier. This barrier directory will prevent processes within the session from traversing it. Since the processes are not allowed to traverse the directory, they are unable to access files outside of the session's file system names- pace. Therefore, by combining the inability for DeskPod processes to access any files outside of the DeskPod storage device's file system, as well as the inability for the processes to run with privilege, the processes are confined to the Desk- Pod session and can't affect change on the DeskPod host.

Display Virtualization

Display virtualization is necessary to ensure that applications can be properly redisplayed when they are moved from one computer to another. This requires that all of an application's display state be captured. Modern graphical applications display their output to a window system, which then processes the display commands to a video device driver to be rendered to the computer's frame buffer so that it appears on the computer's screen. As a result, the display state associated with an application is distributed at different times between the window system and the hardware frame buffer. Since a window system may contain display state for many applications, identifying and extracting the display state for a particular application in an application transparent manner is difficult. Since frame buffer hardware varies from one system to another, extracting the display state for a particular application from a particular frame- buffer in a manner that is portable across different systems is also difficult given that such state is often tied closely to the specifics of the particular physical display device used.

DeskPod will virtualize the display associated with a desktop computing session so that it can be viewed on different hosts that may have different display systems available. Building on my previous work [1], Desk- Pod virtualization will provide each desktop computing session with its own virtual display server and virtual device driver to decouple the display of the desktop computing session from the display subsystem of the host. The virtual display server will provide a DeskPod session with its own window system separate from the window system on the host, thereby separating DeskPod application display state from other applications running on the host outside of the DeskPod session. The display server will be considered as a part of the DeskPod session and will be check pointed when the DeskPod session is suspended and restarted when the DeskPod session is resumed. The virtual display device will process the display commands and directs their output to memory instead of a frame buffer. This approach will abstract away the specific implementation of video card features into a high-level view that is applicable to all video cards. Since the device state will not be in the physical device but it will be present in the virtualized DeskPod session, this simplifies display state management during check pointing and restarting a DeskPod session. As a result, check pointing the display state of a DeskPod session can be done by simply saving the associated memory instead of needing to extract display state from the host-specific frame buffer.

DeskPod's video hardware layer approach will allow it to take full advantage of existing infrastructure and application-hardware interfaces. Furthermore, new video hardware features can be supported with at most the same amount of work necessary for supporting them in traditional desktop display drivers. For example, DeskPod will provide direct video playback support by leveraging existing application interfaces and standard YUV video formats natively supported by almost all off-the-shelf video cards available today. Video data can simply be transferred from the Desk- Pod's virtual display driver to the host's video hardware, which automatically does inexpensive, high speed, color space conversion and scaling.

Rather than sending display commands to local display hardware, the DeskPod virtual video driver will package up display commands associated with a user's computing session, will write them to memory, and enables them to be viewed using a DeskPod viewer application that runs in the context of the window system on the host. The viewer will be completely decoupled from the rest of the DeskPod display system. All it does is, it will read the persistent display state managed by the DeskPod display system. The viewer can be disconnected and reconnected to the DeskPod session at any time without loss of display information since it does not maintain any persistent display state. To enable DeskPod to be viewed on hosts with different display resolutions, the DeskPod viewer will be resolution independent and can scale the display to any size.

DeskPod Checkpoint/Restart

DeskPod will combine its virtualization with a checkpoint- restart mechanism [9] that allows the DeskPod device to be check pointed, transported and restarted across computers with different hardware and operating system kernels. DeskPod will be limited to migrating between machines with a common CPU architecture, and where kernel differences are limited to maintenance and security patches. Also, migration will limited to scenarios where the application's execution semantics, such as how threads are implemented or dynamic linking is performed, stay constant. Since the session's user-space libraries migrate with it, the semantics stay constant.

To support migration across different kernels, DeskPod's checkpoint-restart mechanism will employ an intermediate format to represent the state that needs to be saved. Although the internal state that the kernel maintains on behalf of processes can be different across kernels, the high-level properties of the process are much less likely to change. DeskPod will capture the state of a process in terms of this higher-level semantic information rather than the kernel specific data. DeskPod's intermediate representation format will be chosen such that it offers the degree of portability needed for migrating between different kernel minor versions. If the representation of state is too high-level, the checkpoint-restart mechanism will become complicated and impose additional overhead. The VM area abstraction is standard even across major Linux kernel revisions. DeskPod will view the VM area abstraction as offering sufficient portability in part because the organization of a process's address space in this manner has been standard across all Linux kernels and has never changed since its inception.

DeskPod will leverage high-level native kernel services in order to transform the intermediate representation of the check pointed image into the internal state required by the target kernel. Security patches and minor version kernel revisions commonly involve modifying the internal details of the kernel while high-level primitives remain unchanged. As such, high-level functions are usually made available to kernel modules through the exported kernel symbol interface. Therefore, the DeskPod system will be able to perform cross-kernel migration without requiring modifications to the kernel.

To eliminate possible dependencies on low-level kernel details, DeskPod's checkpoint-restart mechanism will require processes to be suspended prior to being check pointed. Suspending processes will create a quiescent state necessary to guarantee the correctness of the check pointed image, and it will also minimizes the amount of information that needs to be saved. As a representative example, consider the case of semaphore wait queues. Although semaphore values can be easily obtained and restored through well-known interfaces, saving and restoring the state of the wait queue involves the manipulation of kernel internals. However, DeskPod will be able to take advantage of existing semantics which direct the kernel to release a process from a wait queue upon receipt of a signal. DeskPod will use this semantic to empty the wait queues by suspending all processes with a signal, and therefore avoids having to save the state of the queue.

Finally, we must ensure that any changes in the system call interfaces are properly accounted for. As DeskPod has a virtualization layer that uses system call interposition to maintain namespace consistency, a change in the semantics for any system call intercepted could be an issue in migrating across different kernel versions. But such changes usually do not occur, as it would require system libraries to be rewritten. In other words, DeskPod virtualization will be protected from such changes in the same way legacy applications are protected. However, new system calls are added from time to time. Such system calls could have implications to the encapsulation mechanism.

Since processes within a DeskPod session will only have access to devices through the virtual device drivers provided by the DeskPod, it makes it simple to checkpoint the device specific data associated with the processes. In particular, since the DeskPod display system is built using its own virtual display device driver which is not tied to any specific hardware device, such virtual device state can be more easily checkpointed. Because the virtual device state will be totally stored in regular memory, it is a simple matter of saving that state on checkpoint and restoring it on restart. When the DeskPod viewer on the host reconnects to the virtual display driver, it will able to display the user's session.

DELIVERABLES

The final product of this research will be a DeskPod, a portable system that decouples a desktop computing environment from any single hardware device so that it can be stored and executed anywhere. It provides the end users the ease to carry his DeskPod session wherever he goes. A user will start DeskPod by plugging in a DeskPod portable storage device into the computer. The computer detects the device and automatically tries to restart the DeskPod session. DeskPod will mount its encrypted file system, restarts its desktop computing session, and attaches a DeskPod viewer to the session to make the DeskPod session and its applications available and visible to the user. Once DeskPod is started, a user can continue to use their applications, data and the saved execution state. When the user wants to leave the computer, the user simply closes the DeskPod viewer. This causes the DeskPod session to be quickly check pointed to the DeskPod storage device, which can then be unplugged and carried around by the user.

TIMELINE:

DeskPod will virtualize the underlying host operating system and display to decouple DeskPod desktop computing sessions from the underlying host used for execution. This is essential to allow DeskPod applications to be isolated from the underlying system and other applications, to be check pointed on one machine and restarted on another, and to be displayed on hosts with different display hardware and display resolution. Given the large existing base of desktop applications and commodity operating systems, DeskPod virtualization will be designed to be completely transparent to work with existing unmodified applications and operating system kernels. In order to complete all these tasks, a timeline of 5-6 months is needed to completely build the DeskPod and 1 month to test its technical efficiency, compatibility with other operating systems, performance and ease of use.

CONCLUSIONS:

DeskPod, a portable system will introduce a new form of fault-resilient computing. It will enable the users to decouple their computing experience from multiple pieces of hardware that are prone to faults, while providing them with the same persistent, personalized desktop computing session they expect from a regular machine. DeskPod will allow an entire desktop computing session to be stored on a small portable storage device that can be easily carried on a key chain or in a user's pocket, thereby allowing the user increased mobility.

DeskPod will provide its functionality by virtualizing operating system and display resources, decoupling the desk- top computing session from the host on which it is currently running. DeskPod virtualization will work together with a checkpoint/restart mechanism to enable DeskPod users to suspend their desktop computing sessions, move around, and resume their respective sessions at a later time on any computer right where they left off. DeskPod's ability to migrate desktop computing sessions between differently configured and administered computers will provide for increased fault-resilience in the face of faulty computers.

DeskPod will support desktop applications without any changes to the applications or the underlying host operating systems kernels. DeskPod will have low virtualization overhead and can migrate desktop computing sessions with sub-second checkpoint/restart times, providing superior fault-resilience than other proposed solutions. DeskPod will be unique in its ability to provide a complete, persistent, and consistent desktop computing environment among multiple disparate fault-prone computers.