You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by ke...@apache.org on 2013/10/08 21:28:14 UTC

[70/70] git commit: updating sections of the Cloud Infrastructure Concepts chapter of the Admin Guide

updating sections of the Cloud Infrastructure Concepts chapter of the Admin Guide


Project: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/repo
Commit: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/commit/941c197b
Tree: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/tree/941c197b
Diff: http://git-wip-us.apache.org/repos/asf/cloudstack-docs/diff/941c197b

Branch: refs/heads/master
Commit: 941c197b51e66ffea70658532c65304d7a80a1d4
Parents: f38572c
Author: Travis Graham <t...@tgraham.us>
Authored: Thu Oct 3 17:07:19 2013 -0400
Committer: David Nalley <da...@gnsa.us>
Committed: Fri Oct 4 10:31:10 2013 -0400

----------------------------------------------------------------------
 en-US/about-clusters.xml               | 2 +-
 en-US/about-secondary-storage.xml      | 2 +-
 en-US/system-reserved-ip-addresses.xml | 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)
----------------------------------------------------------------------


http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/941c197b/en-US/about-clusters.xml
----------------------------------------------------------------------
diff --git a/en-US/about-clusters.xml b/en-US/about-clusters.xml
index aa8604c..d2f0220 100644
--- a/en-US/about-clusters.xml
+++ b/en-US/about-clusters.xml
@@ -56,7 +56,7 @@
     </para>
     <para>
        When VMware is used, every VMware cluster is managed by a vCenter server.
-       Administrator must register the vCenter server with &PRODUCT;. There may
+       An Administrator must register the vCenter server with &PRODUCT;. There may
        be multiple vCenter servers per zone. Each vCenter server may manage 
        multiple VMware clusters.
     </para>

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/941c197b/en-US/about-secondary-storage.xml
----------------------------------------------------------------------
diff --git a/en-US/about-secondary-storage.xml b/en-US/about-secondary-storage.xml
index 516ec0e..be2ae27 100644
--- a/en-US/about-secondary-storage.xml
+++ b/en-US/about-secondary-storage.xml
@@ -45,7 +45,7 @@
         When using one of these storage plugins, you configure Swift or S3 storage for
         the entire &PRODUCT;, then set up the NFS Secondary Staging Store for each zone. The NFS
         storage in each zone acts as a staging area through which all templates and other secondary
-        storage data pass before being forwarded to Swoft or S3.
+        storage data pass before being forwarded to Swift or S3.
         The backing object storage acts as a cloud-wide
         resource, making templates and other data available to any zone in the cloud.</para>
 </section>

http://git-wip-us.apache.org/repos/asf/cloudstack-docs/blob/941c197b/en-US/system-reserved-ip-addresses.xml
----------------------------------------------------------------------
diff --git a/en-US/system-reserved-ip-addresses.xml b/en-US/system-reserved-ip-addresses.xml
index 7ae9fa8..c3078a2 100644
--- a/en-US/system-reserved-ip-addresses.xml
+++ b/en-US/system-reserved-ip-addresses.xml
@@ -31,7 +31,7 @@
     <para>Provide private IPs for the system in each pod and provision them in &PRODUCT;.</para>
     <para>For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you expect a pod to grow, add enough private IPs now to accommodate the growth.</para>
     <para><emphasis role="bold">In a zone that uses advanced networking:</emphasis></para>
-    <para>For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required &PRODUCT; System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see Working with System Virtual Machines in the Administrator's Guide.</para>
+    <para>For zones with advanced networking, we recommend provisioning enough private IPs for your total number of customers, plus enough for the required &PRODUCT; System VMs. Typically, about 10 additional IPs are required for the System VMs. For more information about System VMs, see <xref linkend="working-with-system-vm"/> in the Administrator's Guide.</para>
     <para>When advanced networking is being used, the number of private IP addresses available in each pod varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM use link-local addresses, which in theory provide more than 65,000 private IP addresses within the address block. As the pod grows over time, this should be more than enough for any reasonable number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.</para>
     <para>To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced networking, use one or both of the following techniques:</para>
     <itemizedlist>