diff --git a/docs/en-US/Release_Notes.xml b/docs/en-US/Release_Notes.xml
index f3f160227af..facd144cf40 100644
--- a/docs/en-US/Release_Notes.xml
+++ b/docs/en-US/Release_Notes.xml
@@ -221,6 +221,28 @@ under the License.
check policies in the cloud. You can override this value for an individual health check
policy.
+
+ Snaphotting, backups, cloning and System VMs for RBD Primary Storage
+
+ These new RBD features require at least librbd 0.61.7 (Cuttlefish) and libvirt
+ 0.9.14 on the KVM hypervisors.
+
+ With this release &PRODUCT; will leverage the features of RBD format 2. This allows
+ snapshotting and backing up those snapshots.
+ Backups of snapshots to Secondary Storage are full copies of the RBD snapshot, they
+ are not RBD diffs. This because when restoring a backup of a snapshot it is not mandatory
+ that this backup is deployed on RBD again, it could also be a NFS Primary Storage.
+ Another key feature of RBD format 2 is cloning and with this release templates will be
+ copied to Primary Storage once and using the cloning mechanism new disks will be cloned
+ from this parent template. This saves space and decreases deployment time for Instances
+ dramatically.
+ Before this release a NFS Primary Storage was still required for running the System
+ VMs from. The reason behind this was a so called 'patch disk' which was generated by the
+ hypervisor which contained metadata for the System VM. The scripts generating this disk
+ didn't support RBD and thus System VMs had to be deployed from NFS. With 4.2 instead of
+ the patch disk a VirtIO serial console is used to pass meta information to System VMs.
+ This enabled the deployment of System VMs on RBD Primary Storage.
+
Issues Fixed in 4.2.0
@@ -386,6 +408,14 @@ under the License.
+
+ CLOUDSTACK-2709
+
+ VM Migration across VMware clusters which are added with different switches
+ (Standard Swith,Vmware DVS, Cisco Nexus 1000v) is not supported..
+
+
CLOUDSTACK-4207
@@ -1268,7 +1298,6 @@ service cloudstack-agent start
# apt-get update
# apt-get upgrade cloud-*
-
Edit /etc/cloudstack/agent/agent.properties to change the
resource parameter from
diff --git a/docs/en-US/change-network-offering-on-guest-network.xml b/docs/en-US/change-network-offering-on-guest-network.xml
index 2c7db3e9176..be99835a774 100644
--- a/docs/en-US/change-network-offering-on-guest-network.xml
+++ b/docs/en-US/change-network-offering-on-guest-network.xml
@@ -20,34 +20,49 @@
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
--->
+-->
- Changing the Network Offering on a Guest Network
- A user or administrator can change the network offering that is associated with an existing guest network.
-
- Log in to the &PRODUCT; UI as an administrator or end user.
- If you are changing from a network offering that uses the &PRODUCT; virtual router to one
- that uses external devices as network service providers, you must first stop all the
- VMs on the network.
- See "Stopping and Starting Virtual Machines" in the Administrator's Guide.
- See .
- In the left navigation, choose Network.
- Click the name of the network you want to modify.
- In the Details tab, click Edit.
-
-
-
-
- EditButton.png: button to edit a network
-
-
- In Network Offering, choose the new network offering, then click Apply.
- A prompt is displayed asking whether you want to keep the existing CIDR. This is to let you
- know that if you change the network offering, the CIDR will be affected. Choose No
- to proceed with the change.
- Wait for the update to complete. Don’t try to restart VMs until the network change is
- complete.
- If you stopped any VMs, restart them.
-
-
-
+ Changing the Network Offering on a Guest Network
+ A user or administrator can change the network offering that is associated with an existing
+ guest network.
+
+
+ Log in to the &PRODUCT; UI as an administrator or end user.
+
+
+ If you are changing from a network offering that uses the &PRODUCT; virtual router to
+ one that uses external devices as network service providers, you must first stop all the VMs
+ on the network. See .
+
+
+ In the left navigation, choose Network.
+
+
+ Click the name of the network you want to modify.
+
+
+ In the Details tab, click Edit.
+
+
+
+
+ EditButton.png: button to edit a network
+
+
+
+
+ In Network Offering, choose the new network offering, then click Apply.
+ A prompt is displayed asking whether you want to keep the existing CIDR. This is to let
+ you know that if you change the network offering, the CIDR will be affected.
+ If you upgrade between virtual router as a provider and an external network device as
+ provider, acknowledge the change of CIDR to continue, so choose Yes.
+
+
+ Wait for the update to complete. Don’t try to restart VMs until the network change is
+ complete.
+
+
+ If you stopped any VMs, restart them.
+
+
+
diff --git a/docs/en-US/guest-traffic.xml b/docs/en-US/guest-traffic.xml
index bca635582a8..c55c7e1b97d 100644
--- a/docs/en-US/guest-traffic.xml
+++ b/docs/en-US/guest-traffic.xml
@@ -23,15 +23,20 @@
-->
Guest Traffic
- A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
- This figure illustrates a typical guest traffic setup:
-
-
-
-
- Depicts a guest traffic setup.
-
- The Management Server automatically creates a virtual router for each network. A virtual router is a special virtual machine that runs on the hosts. Each virtual router has three network interfaces. Its eth0 interface serves as the gateway for the guest traffic and has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the virtual router. Its eth2 interface is assigned a public IP address for public traffic.
+ A network can carry guest traffic only between VMs within one zone. Virtual machines in different zones cannot communicate with each other using their IP addresses; they must communicate with each other by routing through a public IP address.
+ See a typical guest traffic setup given below:
+
+
+
+
+ guest-traffic-setup.png: Depicts a guest traffic setup
+
+ The Management Server automatically creates a virtual router for each network. A virtual
+ router is a special virtual machine that runs on the hosts. Each virtual router in an isolated
+ network has three network interfaces. If multiple public VLAN is used, the router will have
+ multiple public interfaces. Its eth0 interface serves as the gateway for the guest traffic and
+ has the IP address of 10.1.1.1. Its eth1 interface is used by the system to configure the
+ virtual router. Its eth2 interface is assigned a public IP address for public traffic.
The virtual router provides DHCP and will automatically assign an IP address for each guest VM within the IP range assigned for the network. The user can manually reconfigure guest VMs to assume different IP addresses.
Source NAT is automatically configured in the virtual router to forward outbound traffic for all guest VMs
diff --git a/docs/en-US/pvlan.xml b/docs/en-US/pvlan.xml
index eb4c1d85c13..38b25319faf 100644
--- a/docs/en-US/pvlan.xml
+++ b/docs/en-US/pvlan.xml
@@ -223,15 +223,15 @@
IP Range: A range of IP addresses that are
accessible from the Internet and are assigned to the guest VMs.
- If one NIC is used, these IPs should be in the same CIDR in the case of
- IPv6.
+
-
+
Network Domain: A custom DNS suffix at the level
of a network. If you want to assign a special domain name to the guest VM network,
diff --git a/docs/en-US/site-to-site-vpn.xml b/docs/en-US/site-to-site-vpn.xml
index a5899eac4f1..9a41a0adf82 100644
--- a/docs/en-US/site-to-site-vpn.xml
+++ b/docs/en-US/site-to-site-vpn.xml
@@ -3,6 +3,7 @@
%BOOK_ENTITIES;
]>
+