Registry Disk user-guide update

SUMMARY.md

@@ -8,6 +8,7 @@
     * [Creation](vm-creation.md)
     * [Life-cycle](vm-life-cycle.md)
     * [Access](access.md)
+    * [Ephemeral Registry Disks](registry-disk.md)
   * Controllers
     * [Live-Migration](live-migration.md)
     * [Virtual Machine Replica Set](replicaset.md)

registry-disk.md

@@ -0,0 +1,77 @@
+## Registry Disk
+
+The Registry Disk feature provides the ability to store and distribute Virtual
+Machine disks in the container image registry. Registry Disks can be assigned
+to Virtual Machines in the disks section of the Virtual Machine spec.
+
+## When to use a Registry Disk
+
+Registry Disks are ephemeral storage devices that can be assigned to any number
+of active Virtual Machines. This makes them an ideal tool for users who want
+to replicate a large number of Virtual Machine workloads that do not require
+persistent data. Registry Disks are commonly used in conjunction with Virtual
+Machine Replica Sets.
+
+## When Not to use a Registry Disk
+
+Registry Disks are not a good solution for any workload that requires persistent
+disks across Virtual Machine restarts, or workloads that require Virtual
+Machine live migration support. It is possible Registry Disks may gain live
+migration support in the future, but at the moment live migrations are
+incompatible with Registry Disks. 
+
+## Registry Disk Workflow Example
+
+Users push Virtual Machine disks into the container registry using a KubeVirt
+base designed to work with the Registry Disk feature. The latest base container
+image is  kubevirt.io/registry-disk-v1alpha.
+
+Using this base image, users can inject a Virtual Machine disk into a container
+image in a way that is consumable by the KubeVirt runtime. Disks placed into
+the base container must be placed into the /disk directory. Raw and qcow2
+formats are supported. Qcow2 is recommended in order to reduce the container
+image's size.
+
+Example: Inject a Virtual Machine disk into a container image.
+```
+cat << END > Dockerfile 
+FROM kubevirt.io/registry-disk-v1alpha
+ADD fedora25.qcow2 /disk
+END
+
+docker build -t vmdisks/fedora25:latest .
+```
+
+Example: Upload the RegistryDisk container image to a registry.
+```
+docker push vmdisks/fedora25:latest
+```
+
+Example: Attach the RegistryDisk as an ephemeral disk to a virtual machine.
+```
+metadata:
+  name: testvm-ephemeral
+apiVersion: kubevirt.io/v1alpha1
+kind: VirtualMachine
+spec:
+  domain:
+    devices:
+      disks:
+      - type: RegistryDisk:v1alpha
+        source:
+          name: vmdisks/fedora25:latest
+        target:
+          dev: vda
+      interfaces:
+      - source:
+          network: default
+        type: network
+    memory:
+      unit: MB
+      value: 1024
+    os:
+      type:
+        os: hvm
+    type: qemu
+
+```

replicaset.md

@@ -63,7 +63,7 @@ A workload redistributor  needs to be aware of KubeVirt and create Migrations,
 instead of `evicting` VirtualMachines by deletion.
 
 > **Note:** The simplest form of having a migratable ephemeral VirtualMachine,
-> will be to use local storage based on `ContainerRegistryDisks` in combination
+> will be to use local storage based on `RegistryDisks` in combination
 > with a file based backing store. However, migratable backing store
 > support did not yet land in KubeVirt.
 
@@ -96,7 +96,7 @@ spec:
           video:
           - type: qxl
           disks:
-          - type: ContainerRegistryDisk:v1alpha
+          - type: RegistryDisk:v1alpha
             source:
               name: kubevirt/cirros-registry-disk-demo:devel
             target:
@@ -152,7 +152,7 @@ Spec:
               Name:	kubevirt/cirros-registry-disk-demo:devel
             Target:
               Dev:	vda
-            Type:	ContainerRegistryDisk:v1alpha
+            Type:	RegistryDisk:v1alpha
           Graphics:
             Listen:
               Type: