Merge release branch 4.19 to 4.20

* 4.19:
  system vm destroy behaviour (#468)
  Add section about Domain VPCs (#410)
  Updating security group documentation (#469)
  vxlan prefix must be given to prevent interpretation as vlan (#465)

Author: DaanHoogland

source/adminguide/networking/multiple_subnets_in_shared_network.rst

@@ -95,6 +95,8 @@ Adding Multiple Subnets to a Shared Network
       defaulted to the vlan of the network or if vlan of the network is
       null - to Untagged
 
+.. note:: If the VNI is of a VXLAN, the protocol prefix `vxlan://` must be used, like in `vxlan://<vni>`
+
 #. Click OK.
 
 

source/adminguide/networking/security_groups.rst

@@ -27,7 +27,8 @@ rules filter network traffic according to the IP address that is
 attempting to communicate with the instance. Security groups are particularly
 useful in zones that use basic networking, because there is a single
 guest network for all Guest Instances. In advanced zones, security groups are
-supported only on the KVM hypervisor.
+supported only on the KVM hypervisor and XenServer/XCP-ng with the network backend
+configured as "bridge". 
 
 .. note:: 
    In a zone that uses advanced networking, you can instead define 
@@ -41,8 +42,7 @@ desired set of rules.
 Any CloudStack user can set up any number of additional security groups.
 When a new instance is launched, it is assigned to the default security group
 unless another user-defined security group is specified. An instance can be a
-member of any number of security groups. Once an instance is assigned to a
-security group, it remains in that group for its entire lifetime; you
+member of any number of security groups. You can change the security groups of an instance only in a stopped state; you
 can not move a running instance from one security group to another.
 
 You can modify a security group by deleting or adding any number of

source/adminguide/networking/virtual_private_cloud_config.rst

@@ -1448,6 +1448,26 @@ Editing, Restarting, and Removing a Virtual Private Cloud
    |restart-vpc.png|
 
 
+Working with Domain VPCs
+~~~~~~~~~~~~~~~~~~~~~~~~
+
+The functionality of domain VPCs allows operators to aggregate multiple
+Network Tiers from distinct users on the same VPC, reducing the number of virtual
+routers necessary in the environment, and consequently, decreasing the
+amount of public IP addresses consumed. All Network Tiers added to the VPC share
+the same VR, but each one has their own broadcast domain and features
+implemented by the VPC, such as DHCP, NAT, and so on.
+
+In order to utilize this functionality, a new Network Tier must be included to an
+existing VPC by inputing the respective data for the account and the VPC
+on the **'createNetwork'** API. It is important to note that, in order
+for a Network Tier of a different account to be created on the VPC, the account
+that creates the Network Tier must have access to both the account that owns the
+VPC and the account that owns the Network Tier. The owner of the VPC must also
+have access to the account that owns the Network Tier, however, the opposite
+is not required.
+
+
 .. |add-vpc.png| image:: /_static/images/add-vpc.png
    :alt: adding a vpc.
 .. |add-tier.png| image:: /_static/images/add-tier.png

source/adminguide/systemvm.rst

@@ -17,7 +17,7 @@
 CloudStack uses several types of system Instances to perform
 tasks in the cloud. In general CloudStack manages these system VMs and
 creates, starts, and stops them as needed based on scale and immediate
-needs. However, the administrator should be aware of them and their
+needs. Unlike user VMs, system VMs are expunged on destroying them. However, the administrator should be aware of them and their
 roles to assist in debugging issues.
 
 

source/installguide/configuration.rst

@@ -637,6 +637,8 @@ Core Zone
 
    -  **VLAN / VNI ID.** The VLAN / VNI ID's that will be used for guest traffic.
 
+.. note:: If the VNI is of a VXLAN, the protocol prefix `vxlan://` must be used, like in `vxlan://<vni>`
+
 #. In a new pod, CloudStack adds the first cluster for you. You can
    always add more clusters later. For an overview of what a cluster is,
    see :ref:`about-clusters`