Merge "Adding mock-detached util function and cleaning up util help output"

[apex.git] / docs / installation-instructions / virtualinstall.rst

diff --git a/docs/installation-instructions/virtualinstall.rst b/docs/installation-instructions/virtualinstall.rst
index 7232952..c2ee66d 100644 (file)
--- a/docs/installation-instructions/virtualinstall.rst
+++ b/docs/installation-instructions/virtualinstall.rst
@@ -1,24 +1,20 @@
 Installation High-Level Overview - Virtual Deployment
 =====================================================
 
-The VM nodes deployment operates almost the same way as the bare metal deploymen
-t with a
-few differences.  ``opnfv-deploy`` still deploys an Instack VM. In addition to t
-he Instack VM
-a collection of VMs (3 control nodes + 2 compute for an HA deployment or 1 contr
-ol node and
-1 compute node for a Non-HA Deployment) will be defined for the target OPNFV dep
-loyment.
-The part of the toolchain that executes IPMI power instructions calls into libvi
-rt instead of
+The VM nodes deployment operates almost the same way as the bare metal
+deployment with a few differences.  ``opnfv-deploy`` still deploys an Undercloud
+VM. In addition to the Undercloud VM a collection of VMs (3 control nodes + 2
+compute for an HA deployment or 1 control node and 1 compute node for a Non-HA
+Deployment) will be defined for the target OPNFV deployment.  The part of the
+toolchain that executes IPMI power instructions calls into libvirt instead of
 the IPMI interfaces on baremetal servers to operate the power managment.  These
-VMs are then
-provisioned with the same disk images and configuration that baremetal would be.
-
-To RDO Manager these nodes look like they have just built and registered the sam
-e way as
-bare metal nodes, the main difference is the use of a libvirt driver for the pow
-er management.
+VMs are then provisioned with the same disk images and configuration that
+baremetal would be. To Triple-O these nodes look like they have just built
+and registered the same way as bare metal nodes, the main difference is the use
+of a libvirt driver for the power management. Finally, the default
+network_settings file will deploy without modification. Customizations
+are welcome but not needed if a generic set of network_settings are
+acceptable.
 
 Installation Guide - Virtual Deployment
 =======================================
@@ -40,19 +36,20 @@ the configuration nessesary to deploy OPNFV with no modifications.
 If no modifications are made to the included configurations the target environment
 will deploy with the following architecture:
 
-    - 1 Instack VM
+    - 1 Undercloud VM
 
-    - The option of 3 control and 2 compute VMs (HA Deploy / default)
-      or 1 control and 1 compute VM (Non-HA deploy / pass -n)
+    - The option of 3 control and 2 or more compute VMs (HA Deploy / default)
+      or 1 control and 1 or more compute VM (Non-HA deploy / pass -n)
 
-    - 2 networks, one for provisioning, internal API,
-      storage and tenant networking traffic and a second for the external network
+    - 2-4 networks: provisioning / internal API, storage, private tenant networking
+      and the external network. The storage and tenant networking networks
+      can be collapsed onto the provisioning network.
 
 Follow the steps below to execute:
 
-1.  ``sudo opnfv-deploy --virtual [ --no-ha ]``
+1.  ``sudo opnfv-deploy [ --flat ] -n network_settings.yaml -i inventory.yaml -d deploy_settings.yaml``
 
-2.  It will take approximately 30 minutes to stand up instack,
+2.  It will take approximately 45 minutes to an hour to stand up Undercloud,
     define the target virtual machines, configure the deployment and execute the deployment.
     You will notice different outputs in your shell.