path: root/docs/release/installation/virtual.rst
diff options
Diffstat (limited to 'docs/release/installation/virtual.rst')
1 files changed, 84 insertions, 13 deletions
diff --git a/docs/release/installation/virtual.rst b/docs/release/installation/virtual.rst
index 9336b8e..a844d43 100644
--- a/docs/release/installation/virtual.rst
+++ b/docs/release/installation/virtual.rst
@@ -3,20 +3,36 @@ Installation High-Level Overview - Virtual Deployment
Deploying virtually is an alternative deployment method to bare metal, where
only a single bare metal Jump Host server is required to execute deployment.
-In this deployment type, the Jump Host server will host the undercloud VM along
-with any number of OPNFV overcloud control/compute nodes. This deployment type
-is useful when physical resources are constrained, or there is a desire to
-deploy a temporary sandbox environment.
+This deployment type is useful when physical resources are constrained, or
+there is a desire to deploy a temporary sandbox environment.
+With virtual deployments, two deployment options are offered. The first is a
+standard deployment where the Jump Host server will host the undercloud VM along
+with any number of OPNFV overcloud control/compute nodes. This follows the same
+deployment workflow as baremetal, and can take between 1 to 2 hours to complete.
+The second option is to use snapshot deployments. Snapshots are saved disk images
+of previously deployed OPNFV upstream. These snapshots are promoted daily and contain
+and already deployed OPNFV environment that has passed a series of tests. The
+advantage of the snapshot is that it deploys in less than 10 minutes. Another
+major advantage is that the snapshots work on both CentOS and Fedora OS. Note:
+Fedora support is only tested via PIP installation at this time and not via RPM.
+Standard Deployment Overview
The virtual deployment operates almost the same way as the bare metal
deployment with a few differences mainly related to power management.
``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 or more compute nodes for a Non-HA Deployment) will be
+control node and 0 or more compute nodes for a Non-HA Deployment) will be
defined for the target OPNFV deployment. All overcloud VMs are registered
with a Virtual BMC emulator which will service power management (IPMI)
commands. The overcloud VMs are still provisioned with the same disk images
-and configuration that baremetal would use.
+and configuration that baremetal would use. Using 0 nodes for a virtual
+deployment will automatically deploy "all-in-one" nodes which means the compute
+will run along side the controller in a single overcloud node. Specifying 3
+control nodes will result in a highly-available service model.
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
@@ -24,6 +40,23 @@ the power management. Finally, the default network settings file will deploy wi
modification. Customizations are welcome but not needed if a generic set of
network settings are acceptable.
+Snapshot Deployment Overview
+Snapshot deployments use the same ``opnfv-deploy`` CLI as standard deployments.
+The snapshot deployment will use a cache in order to store snapshots that are
+downloaded from the internet at deploy time. This caching avoids re-downloading
+the same artifact between deployments. The snapshot deployment recreates the same
+network and libvirt setup as would have been provisioned by the Standard
+deployment, with the exception that there is no undercloud VM. The snapshot
+deployment will give the location of the RC file to use in order to interact
+with the Overcloud directly from the jump host.
+Snapshots come in different topology flavors. One is able to deploy either HA
+(3 Control, 2 Computes, no-HA (1 Control, 2 Computes), or all-in-one
+(1 Control/Compute. The snapshot deployment itself is always done with the
+os-odl-nofeature-* scenario.
Installation Guide - Virtual Deployment
@@ -54,8 +87,8 @@ Install Jump Host
Follow the instructions in the `Install Bare Metal Jump Host`_ section.
-Running ``opnfv-deploy``
+Running ``opnfv-deploy`` for Standard Deployment
You are now ready to deploy OPNFV!
``opnfv-deploy`` has virtual deployment capability that includes all of
@@ -67,7 +100,7 @@ environment will deploy with the following architecture:
- 1 undercloud VM
- 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)
+ or 1 control and 0 or more compute VMs (Non-HA deploy)
- 1-5 networks: provisioning, private tenant networking, external, storage
and internal API. The API, storage and tenant networking networks can be
@@ -80,10 +113,11 @@ Follow the steps below to execute:
-n network_settings.yaml -d deploy_settings.yaml``
Note it can also be useful to run the command with the ``--debug``
argument which will enable a root login on the overcloud nodes with
- password: 'opnfv-apex'. It is also useful in some cases to surround the
+ password: 'opnfvapex'. It is also useful in some cases to surround the
deploy command with ``nohup``. For example:
``nohup <deploy command> &``, will allow a deployment to continue even if
- ssh access to the Jump Host is lost during deployment.
+ ssh access to the Jump Host is lost during deployment. By specifying
+ ``--virtual-computes 0``, the deployment will proceed as all-in-one.
2. It will take approximately 45 minutes to an hour to stand up undercloud,
define the target virtual machines, configure the deployment and execute
@@ -92,11 +126,48 @@ Follow the steps below to execute:
3. When the deployment is complete the IP for the undercloud and a url for the
OpenStack dashboard will be displayed
+Running ``opnfv-deploy`` for Snapshot Deployment
+Deploying snapshots requires enough disk space to cache snapshot archives, as well
+as store VM disk images per deployment. The snapshot cache directory can be
+configured at deploy time. Ensure a directory is used on a partition with enough
+space for about 20GB. Additionally, Apex will attempt to detect the default
+libvirt storage pool on the jump host. This is typically '/var/lib/libvirt/images'.
+On default CentOS installations, this path will resolve to the /root partition,
+which is only around 50GB. Therefore, ensure that the path for the default storage
+pool has enough space to hold the VM backing storage (approx 4GB per VM). Note,
+each Overcloud VM disk size is set to 40GB, however Libvirt grows these disks
+dynamically. Due to this only 4GB will show up at initial deployment, but the disk
+may grow from there up to 40GB.
+The new arguments to deploy snapshots include:
+ - `--snapshot`: Enables snapshot deployments
+ - `--snap-cache`: Indicates the directory to use for caching artifacts
+An example deployment command is:
+.. code-block::
+ opnfv-deploy -d ../config/deploy/os-odl-queens-noha.yaml --snapshot
+ --snap-cache /home/trozet/snap_cache --virtual-computes 0 --no-fetch
+In the above example, several of the Standard Deployment arguments are still
+used to deploy snapshots:
+ - `-d`: Deploy settings are used to determine OpenStack version of snapshots
+ to use as well as the topology
+ - `--virtual-computes` - When set to 0, it indicates to Apex to use an
+ all-in-one snapshot
+ - `--no-fetch` - Can be used to disable fetching latest snapshot artifact
+ from upstream and use the latest found in `--snap-cache`
Verifying the Setup - VMs
To verify the set you can follow the instructions in the `Verifying the Setup`_
-.. _`Install Bare Metal Jump Host`: index.html#install-bare-metal-jump-host
-.. _`Verifying the Setup`: index.html#verifying-the-setup
+.. _`Install Bare Metal Jump Host`: baremetal.html#install-bare-metal-jump-host
+.. _`Verifying the Setup`: verification.html#verifying-the-setup