Cloud Computing has emerged as a successful computing paradigm for efficiently utilizing managed compute infrastructure such as high speed rack-mounted servers, connected with high speed networking, and reliable storage. Usually such infrastructure is dedicated, physically secured and has reliable power and networking infrastructure. However, much of our idle compute capacity is present in unmanaged infrastructure like idle desktops, lab machines, physically distant server machines, and laptops. We present a scheme to utilize this idle compute capacity on a best-effort basis and provide high availability even in face of failure of individual components or facilities. We run virtual machines on the commodity infrastructure and present a cloud interface to our end users. The primary challenge is to maintain availability in the presence of node failures, network failures, and power failures. We run multiple copies of a Virtual Machine (VM) redundantly on geographically dispersed physical machines to achieve availability. If one of the running copies of a VM fails, we seamlessly switchover to another running copy. We use Virtual Machine Record Replay capability to implement this redundancy and switchover. In current progress, we have implemented VM Record Replay for uniprocessor machines over Linux KVM and are currently working on VM Record Replay on shared-memory multiprocessor machines. We report initial experimental results based on our implementation.
Our current prototype can efficiently record and replay a uniprocessor VM. We have also implemented record replay for multiprocessor VMs. Multiprocessor record replay is significantly harder due to the presence of race conditions on shared memory by multiple processors. We have implemented a page-ownership scheme based on CREW (concurrent read exclusive write) protocol @cite_8 to record and replay a guest OS. We can successfully replay an unmodified guest, albeit at high overheads. The overheads depend on the workload and could be as high as 2-3x slowdowns for 2-processor VMs. Another approach, DoublePlay @cite_6 , has been proposed to make multiprocessor record replay more performant. DoublePlay works by recording the order of all synchronization operations in the program being recorded. Because a guest OS could have arbitrary synchronization primitives, it is hard to directly use DoublePlay's ideas for VM Record Replay. We are currently working on approaches to make multiprocessor VM record replay faster.
@cite_6 @cite_8
2115855199 2171956059
Deterministic replay systems record and reproduce the execution of a hardware or software system. In contrast to replaying execution on uniprocessors, deterministic replay on multiprocessors is very challenging to implement efficiently because of the need to reproduce the order or values read by shared memory operations performed by multiple threads. In this paper, we present DoublePlay, a new way to efficiently guarantee replay on commodity multiprocessors. Our key insight is that one can use the simpler and faster mechanisms of single-processor record and replay, yet still achieve the scalability offered by multiple cores, by using an additional execution to parallelize the record and replay of an application. DoublePlay timeslices multiple threads on a single processor, then runs multiple time intervals (epochs) of the program concurrently on separate processors. This strategy, which we call uniparallelism, makes logging much easier because each epoch runs on a single processor (so threads in an epoch never simultaneously access the same memory) and different epochs operate on different copies of the memory. Thus, rather than logging the order of shared-memory accesses, we need only log the order in which threads in an epoch are timesliced on the processor. DoublePlay runs an additional execution of the program on multiple processors to generate checkpoints so that epochs run in parallel. We evaluate DoublePlay on a variety of client, server, and scientific parallel benchmarks; with spare cores, DoublePlay reduces logging overhead to an average of 15 with two worker threads and 28 with four threads. Execution replay of virtual machines is a technique which has many important applications, including debugging, fault-tolerance, and security. Execution replay for single processor virtual machines is well-understood, and available commercially. With the advancement of multi-core architectures, however, multiprocessor virtual machines are becoming more important. Our system, SMP-ReVirt, is the first system to log and replay a multiprocessor virtual machine on commodity hardware. We use hardware page protection to detect and accurately replay sharing between virtual cpus of a multi-cpu virtual machine, allowing us to replay the entire operating system and all applications. We have tested our system on a variety of workloads, and find that although sharing under SMP-ReVirt is expensive, for many workloads and applications, including debugging, the overhead is acceptable.