docs/release/installation/virtual.rst

   1 Installation High-Level Overview - Virtual Deployment
   2 =====================================================
   3
   4 Deploying virtually is an alternative deployment method to bare metal, where
   5 only a single bare metal Jump Host server is required to execute deployment.
   6 This deployment type is useful when physical resources are constrained, or
   7 there is a desire to deploy a temporary sandbox environment.
   8
   9 With virtual deployments, two deployment options are offered. The first is a
  10 standard deployment where the Jump Host server will host the undercloud VM along
  11 with any number of OPNFV overcloud control/compute nodes. This follows the same
  12 deployment workflow as baremetal, and can take between 1 to 2 hours to complete.
  13
  14 The second option is to use snapshot deployments. Snapshots are saved disk images
  15 of previously deployed OPNFV upstream. These snapshots are promoted daily and contain
  16 and already deployed OPNFV environment that has passed a series of tests. The
  17 advantage of the snapshot is that it deploys in less than 10 minutes. Another
  18 major advantage is that the snapshots work on both CentOS and Fedora OS. Note:
  19 Fedora support is only tested via PIP installation at this time and not via RPM.
  20
  21 Standard Deployment Overview
  22 ----------------------------
  23
  24 The virtual deployment operates almost the same way as the bare metal
  25 deployment with a few differences mainly related to power management.
  26 ``opnfv-deploy`` still deploys an undercloud VM. In addition to the undercloud
  27 VM a collection of VMs (3 control nodes + 2 compute for an HA deployment or 1
  28 control node and 0 or more compute nodes for a Non-HA Deployment) will be
  29 defined for the target OPNFV deployment.  All overcloud VMs are registered
  30 with a Virtual BMC emulator which will service power management (IPMI)
  31 commands.  The overcloud VMs are still provisioned with the same disk images
  32 and configuration that baremetal would use. Using 0 nodes for a virtual
  33 deployment will automatically deploy "all-in-one" nodes which means the compute
  34 will run along side the controller in a single overcloud node. Specifying 3
  35 control nodes will result in a highly-available service model.
  36
  37 To Triple-O these nodes look like they have just built and registered the same
  38 way as bare metal nodes, the main difference is the use of a libvirt driver for
  39 the power management.  Finally, the default network settings file will deploy without
  40 modification.  Customizations are welcome but not needed if a generic set of
  41 network settings are acceptable.
  42
  43 Snapshot Deployment Overview
  44 ----------------------------
  45
  46 Snapshot deployments use the same ``opnfv-deploy`` CLI as standard deployments.
  47 The snapshot deployment will use a cache in order to store snapshots that are
  48 downloaded from the internet at deploy time. This caching avoids re-downloading
  49 the same artifact between deployments. The snapshot deployment recreates the same
  50 network and libvirt setup as would have been provisioned by the Standard
  51 deployment, with the exception that there is no undercloud VM. The snapshot
  52 deployment will give the location of the RC file to use in order to interact
  53 with the Overcloud directly from the jump host.
  54
  55 Snapshots come in different topology flavors. One is able to deploy either HA
  56 (3 Control, 2 Computes, no-HA (1 Control, 2 Computes), or all-in-one
  57 (1 Control/Compute. The snapshot deployment itself is always done with the
  58 os-odl-nofeature-* scenario.
  59
  60 Installation Guide - Virtual Deployment
  61 =======================================
  62
  63 This section goes step-by-step on how to correctly install and provision the
  64 OPNFV target system to VM nodes.
  65
  66 Special Requirements for Virtual Deployments
  67 --------------------------------------------
  68
  69 In scenarios where advanced performance options or features are used, such
  70 as using huge pages with nova instances, DPDK, or iommu; it is required to
  71 enabled nested KVM support.  This allows hardware extensions to be passed to
  72 the overcloud VMs, which will allow the overcloud compute nodes to bring up
  73 KVM guest nova instances, rather than QEMU.  This also provides a great
  74 performance increase even in non-required scenarios and is recommended to be
  75 enabled.
  76
  77 During deployment the Apex installer will detect if nested KVM is enabled,
  78 and if not, it will attempt to enable it; while printing a warning message
  79 if it cannot.  Check to make sure before deployment that Nested
  80 Virtualization is enabled in BIOS, and that the output of ``cat
  81 /sys/module/kvm_intel/parameters/nested`` returns "Y".  Also verify using
  82 ``lsmod`` that the kvm_intel module is loaded for x86_64 machines, and
  83 kvm_amd is loaded for AMD64 machines.
  84
  85 Install Jump Host
  86 -----------------
  87
  88 Follow the instructions in the `Install Bare Metal Jump Host`_ section.
  89
  90 Running ``opnfv-deploy`` for Standard Deployment
  91 ------------------------------------------------
  92
  93 You are now ready to deploy OPNFV!
  94 ``opnfv-deploy`` has virtual deployment capability that includes all of
  95 the configuration necessary to deploy OPNFV with no modifications.
  96
  97 If no modifications are made to the included configurations the target
  98 environment will deploy with the following architecture:
  99
 100     - 1 undercloud VM
 101
 102     - The option of 3 control and 2 or more compute VMs (HA Deploy / default)
 103       or 1 control and 0 or more compute VMs (Non-HA deploy)
 104
 105     - 1-5 networks: provisioning, private tenant networking, external, storage
 106       and internal API. The API, storage and tenant networking networks can be
 107       collapsed onto the provisioning network.
 108
 109 Follow the steps below to execute:
 110
 111 1.  ``sudo opnfv-deploy -v [ --virtual-computes n ]
 112     [ --virtual-cpus n ] [ --virtual-ram n ]
 113     -n network_settings.yaml -d deploy_settings.yaml``
 114     Note it can also be useful to run the command with the ``--debug``
 115     argument which will enable a root login on the overcloud nodes with
 116     password: 'opnfvapex'.  It is also useful in some cases to surround the
 117     deploy command with ``nohup``.  For example:
 118     ``nohup <deploy command> &``, will allow a deployment to continue even if
 119     ssh access to the Jump Host is lost during deployment. By specifying
 120     ``--virtual-computes 0``, the deployment will proceed as all-in-one.
 121
 122 2.  It will take approximately 45 minutes to an hour to stand up undercloud,
 123     define the target virtual machines, configure the deployment and execute
 124     the deployment.  You will notice different outputs in your shell.
 125
 126 3.  When the deployment is complete the IP for the undercloud and a url for the
 127     OpenStack dashboard will be displayed
 128
 129 Running ``opnfv-deploy`` for Snapshot Deployment
 130 ------------------------------------------------
 131
 132 Deploying snapshots requires enough disk space to cache snapshot archives, as well
 133 as store VM disk images per deployment. The snapshot cache directory can be
 134 configured at deploy time. Ensure a directory is used on a partition with enough
 135 space for about 20GB. Additionally, Apex will attempt to detect the default
 136 libvirt storage pool on the jump host. This is typically '/var/lib/libvirt/images'.
 137 On default CentOS installations, this path will resolve to the /root partition,
 138 which is only around 50GB. Therefore, ensure that the path for the default storage
 139 pool has enough space to hold the VM backing storage (approx 4GB per VM). Note,
 140 each Overcloud VM disk size is set to 40GB, however Libvirt grows these disks
 141 dynamically. Due to this only 4GB will show up at initial deployment, but the disk
 142 may grow from there up to 40GB.
 143
 144 The new arguments to deploy snapshots include:
 145
 146   - `--snapshot`: Enables snapshot deployments
 147   - `--snap-cache`: Indicates the directory to use for caching artifacts
 148
 149 An example deployment command is:
 150
 151 .. code-block::
 152
 153   opnfv-deploy -d ../config/deploy/os-odl-queens-noha.yaml --snapshot
 154   --snap-cache /home/trozet/snap_cache --virtual-computes 0 --no-fetch
 155
 156 In the above example, several of the Standard Deployment arguments are still
 157 used to deploy snapshots:
 158
 159   - `-d`: Deploy settings are used to determine OpenStack version of snapshots
 160     to use as well as the topology
 161   - `--virtual-computes` - When set to 0, it indicates to Apex to use an
 162     all-in-one snapshot
 163   - `--no-fetch` - Can be used to disable fetching latest snapshot artifact
 164     from upstream and use the latest found in `--snap-cache`
 165
 166 Verifying the Setup - VMs
 167 -------------------------
 168
 169 To verify the set you can follow the instructions in the `Verifying the Setup`_
 170 section.
 171
 172 .. _`Install Bare Metal Jump Host`: baremetal.html#install-bare-metal-jump-host
 173 .. _`Verifying the Setup`: verification.html#verifying-the-setup