Rename DVM to Hyper

Author: Peng Zhao

README.md

@@ -1,22 +1,22 @@
-# About DVM
+# About Hyper
 
-DVM is a tool (a minimalist kernel called ***HyperKernel***) built for running app container with hypervisor.
+Hyper is a tool (a minimalist kernel called ***HyperKernel***) built for running app container with hypervisor.
 
-Put simply, DVM allows you to run one or multiple app container images (Docker, ACI) on top of hypervisor.
+Put simply, Hyper allows you to run one or multiple app container images (Docker, ACI) on top of hypervisor.
 
-    DVM = Hypervisor + Kernel + App Container Image
+    Hyper = Hypervisor + Kernel + App Container Image
 
-By running independent kernel in each instance, DVM is free from the isolation concern of container. DVM also promises **Immutable Infrastructure** by eliminating the Guest OS middle layer and the hassle to configure and manage the OS.
+By running independent kernel in each instance, Hyper is free from the isolation concern of container. Hyper also promises **Immutable Infrastructure** by eliminating the Guest OS middle layer and the hassle to configure and manage the OS.
 
 ![](https://trello-attachments.s3.amazonaws.com/552cb61fef93933ed62b9135/871x357/1c24746b58ab3aaadd5988216c8c2df1/upload_2015-04-14_at_3.05.23_pm.png)
 
-Performance-wise, **DVM is super light**:
+Performance-wise, **Hyper is super light**:
 
-- **Sub-second Boot**: 0.5 second to launch a DVM instance
+- **Sub-second Boot**: 0.5 second to launch a Hyper instance
 - **Minimal Overhead**: 1-2% CPU overhead
-- **Higher Density**: minimal Mem requirement is 10MB for DVM (512MB on AWS EC2)
+- **Higher Density**: minimal Mem requirement is 10MB for Hyper (512MB on AWS EC2)
 
-We believe that a secure, public, multi-tenant **Cluster-as-a-Service** (CaaS) can be built with DVM.
+We believe that a secure, public, multi-tenant **Cluster-as-a-Service** (CaaS) can be built with Hyper.
 
 ![](https://trello-attachments.s3.amazonaws.com/552ba9ad83b51945d06ef23b/940x238/9e7346bfd21bc756361c70d8397e76f2/upload_2015-04-13_at_7.58.15_pm.png)
 

SUMMARY.md

@@ -1,13 +1,13 @@
 # Summary
 
-* [About DVM](README.md)
-   * [Why DVM](what_is_dvm.md)
+* [About Hyper](README.md)
+   * [Why Hyper](why_hyper.md)
    * [How it works](how_it_works.md)
    * [Performance](performance)
 * [Get Started](get_started/README.md)
    * [Install](get_started/install.md)
-   * [Launch DVM instance](get_started/launch_dvm_instance.md)
-* [DVM Instance](instance/README.md)
+   * [Launch Hyper instance](get_started/launch_instance.md)
+* [Instance](instance/README.md)
    * [Ephemeral & Persistent](instance/ephemeral_&_persistent.md)
    * [CPU](instance/cpu)
    * [Mem](instance/mem)

get_started/launch_dvm_instance.md

@@ -0,0 +1 @@
+# Launch Hyper instance

get_started/launch_instance.md

@@ -2,11 +2,11 @@
 
 On a physical Linux box:
 
-	[root@gnep ~:]# yum install dvm
+	[root@gnep ~:]# yum install hyper
 	[root@gnep ~:]# docker pull nginx:latest
-	[root@gnep ~:]# dvm run nginx:latest
+	[root@gnep ~:]# hyper run nginx:latest
 
-Instead of using LXC, DVM boots the image with a new VM instance:
+Instead of using LXC, Hyper boots the image with a new VM instance:
 
 	[root@gnep ~:]# docker ps
 	[root@gnep ~:]#
@@ -15,16 +15,16 @@ Instead of using LXC, DVM boots the image with a new VM instance:
 
 ## Internal
 
-DVM is comprised of several components:
+Hyper is comprised of several components:
 
 - On the (physical) host:
-  - DVM Daemon
-  - DVM CLI
+  - Hyper Daemon
+  - Hyper CLI
   - (*) REST APIs
 
 - In the VM instance:
-  - HyperKernel - a minimalist kernel built for DVM
-  - DVM Init - a tiny init service
+  - HyperKernel - a minimalist kernel built for Hyper
+  - Hyper Init - a tiny init service
 
 ![](https://trello-attachments.s3.amazonaws.com/552cbb0e30cc49001aaa25fc/872x464/7f1c42bbd4d73b17b7fb3670ef4994bb/upload_2015-04-14_at_3.00.26_pm.png)
 

how_it_works.md

@@ -1,2 +1,2 @@
-# DVM Instance
+# Hyper Instance
 

instance/README.md

@@ -1,14 +1,14 @@
 # Ephemeral & Persistent
 
-Due to the sub-second boot feature, DVM instance could be considered as ephemeral entities, though it certainly clould be also used as long-running and durable.
+Due to the sub-second boot feature, Hyper instance could be considered as ephemeral entities, though it certainly clould be also used as long-running and durable.
 
 - Ephemeral
 
-> In a microservice architecture, apps are scheduled to (physical) hosts, where a new DVM instance is created, the app is loaded into the instance and remains there until termination or deletion. When an app dies (or the instance), the app will be scheduled to another host with new instance. If a host dies, either all apps on the host can be rescheduled, or all instances on the host can be restarted on other hosts (if shared storage available).
+> In a microservice architecture, apps are scheduled to (physical) hosts, where a new Hyper instance is created, the app is loaded into the instance and remains there until termination or deletion. When an app dies (or the instance), the app will be scheduled to another host with new instance. If a host dies, either all apps on the host can be rescheduled, or all instances on the host can be restarted on other hosts (if shared storage available).
 
 - Persistent
 
-> For big data application (Hadoop, Spark), new jobs are consistently dispatched to hosts. Instead of creating ephemeral instances for each task, the application could use persistent DVM instance and "submit" jobs by calling DVM's REST API to replace the binary in the instance.
+> For big data application (Hadoop, Spark), new jobs are consistently dispatched to hosts. Instead of creating ephemeral instances for each task, the application could use persistent Hyper instance and "submit" jobs by calling Hyper's REST API to replace the binary in the instance.
 
 
 

instance/ephemeral_&_persistent.md

@@ -1,3 +1,3 @@
 # License
 
-DVM is licensed under the Apache License, Version 2.0. See [LICENSE](https://www.apache.org/licenses/LICENSE-2.0) for the full license text.
+Hyper is licensed under the Apache License, Version 2.0. See [LICENSE](https://www.apache.org/licenses/LICENSE-2.0) for the full license text.

license.md

@@ -1,6 +1,6 @@
 # What is Pod
 
-Pods is the first-class unit for app deployment and execution in DVM.
+Pods is the first-class unit for app deployment and execution in Hyper.
 
 According to [Google Kuberenetes](https://github.com/GoogleCloudPlatform/kubernetes/blob/master/docs/pods.md):
 
@@ -10,7 +10,7 @@ According to [Google Kuberenetes](https://github.com/GoogleCloudPlatform/kuberne
 
 The key idea behind **Pod** is that in a microservie architecture usually involves some "helper" programs, such like log, monitoring, cron, etc. These helper programs are built to work co-operatively with the app. Therefore, instead of running in multiple isolated containers, these processes should share the same environment, although they are packaged in different images.
 
-In terms of DVM, a pod consists of a colocated group of Docker images, deployed as an atomic unit and loaded into the same DVM instance.
+In terms of Hyper, a pod consists of a colocated group of Docker images, deployed as an atomic unit and loaded into the same Hyper instance.
 
 The context of the pod can be defined as the conjunction of:
 

pod/README.md

@@ -1,17 +1,17 @@
-# Why DVM
+# Why Hyper
 
-DVM combines the best from both worlds: ***Virtualization*** and ***Docker***.
+Hyper combines the best from both worlds: ***Virtualization*** and ***Docker***.
 
 
 ## Security
 
 Virtualization offers an excellent security. The attack surface for a VM instance is quite small, as it lacks the variety of functions (and, therefore, the potential flaws to be exploited) provided by standard operating systems.
 
-More important, DVM is immune from the isolation problem in container.
+More important, Hyper is immune from the isolation problem in container.
 
 ## Immutable
 
-DVM eliminates the need for guest OS. There are no moving parts inside of a DVM instance to be configured or managed, only the kernel and the loaded Docker images.
+Hyper eliminates the need for guest OS. There are no moving parts inside of a Hyper instance to be configured or managed, only the kernel and the loaded Docker images.
 
 Therefore the entire stack is immutable.
 
@@ -21,18 +21,18 @@ Since each VM instance runs its own kernel, tenants have the choice to pick thei
 
 ## Mature
 
-Compared with container, virtualization is production-ready. Features like LiveMigration, SDN, SDS are battle-tested for years. DVM lets you enjoy all these features without any integration work.
+Compared with container, virtualization is production-ready. Features like LiveMigration, SDN, SDS are battle-tested for years. Hyper lets you enjoy all these features without any integration work.
 
 ## Seamless Migration
 
-Virtualization are widespread among enterprises. Many of them have a virtualized infrastructure running. Instead of having to rebuild everything with container, DVM provides a seamless migration path to adopt Docker.
+Virtualization are widespread among enterprises. Many of them have a virtualized infrastructure running. Instead of having to rebuild everything with container, Hyper provides a seamless migration path to adopt Docker.
 
 ## Hypervisor Agnostic
 
-DVM is designed to be independent from the underlying virtualization technology. [The current implementation](----TODO----) supports KVM and Xen, with more virtualization technologies in the roadmap.
+Hyper is designed to be independent from the underlying virtualization technology. [The current implementation](----TODO----) supports KVM and Xen, with more virtualization technologies in the roadmap.
 
 
-You can find the more detailed comparision between DVM and other solutions in the follow articles:
+You can find the more detailed comparision between Hyper and other solutions in the follow articles:
 
 - Container-centric OS (CoreOS, RancherOS, etc)
 -