Return-Path: X-Original-To: apmail-cloudstack-commits-archive@www.apache.org Delivered-To: apmail-cloudstack-commits-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 5955E104EC for ; Fri, 19 Apr 2013 22:41:41 +0000 (UTC) Received: (qmail 3025 invoked by uid 500); 19 Apr 2013 22:41:41 -0000 Delivered-To: apmail-cloudstack-commits-archive@cloudstack.apache.org Received: (qmail 3008 invoked by uid 500); 19 Apr 2013 22:41:41 -0000 Mailing-List: contact commits-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list commits@cloudstack.apache.org Received: (qmail 3001 invoked by uid 99); 19 Apr 2013 22:41:41 -0000 Received: from tyr.zones.apache.org (HELO tyr.zones.apache.org) (140.211.11.114) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 19 Apr 2013 22:41:41 +0000 Received: by tyr.zones.apache.org (Postfix, from userid 65534) id E672681B2C7; Fri, 19 Apr 2013 22:41:40 +0000 (UTC) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: jzb@apache.org To: commits@cloudstack.apache.org Message-Id: X-Mailer: ASF-Git Admin Mailer Subject: git commit: updated refs/heads/4.1 to 4bf22b1 Date: Fri, 19 Apr 2013 22:41:40 +0000 (UTC) Updated Branches: refs/heads/4.1 ab2052506 -> 4bf22b1a0 CLOUDSTACK-382: Clarifying storage type in documentation as secondary storage. Project: http://git-wip-us.apache.org/repos/asf/cloudstack/repo Commit: http://git-wip-us.apache.org/repos/asf/cloudstack/commit/4bf22b1a Tree: http://git-wip-us.apache.org/repos/asf/cloudstack/tree/4bf22b1a Diff: http://git-wip-us.apache.org/repos/asf/cloudstack/diff/4bf22b1a Branch: refs/heads/4.1 Commit: 4bf22b1a0a532e38743ac6cb63869d9414de270c Parents: ab20525 Author: Joe Brockmeier Authored: Fri Apr 19 17:41:23 2013 -0500 Committer: Joe Brockmeier Committed: Fri Apr 19 17:41:23 2013 -0500 ---------------------------------------------------------------------- docs/en-US/advanced-zone-network-traffic-types.xml | 2 +- docs/en-US/basic-zone-network-traffic-types.xml | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) ---------------------------------------------------------------------- http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4bf22b1a/docs/en-US/advanced-zone-network-traffic-types.xml ---------------------------------------------------------------------- diff --git a/docs/en-US/advanced-zone-network-traffic-types.xml b/docs/en-US/advanced-zone-network-traffic-types.xml index d803592..4d1f465 100644 --- a/docs/en-US/advanced-zone-network-traffic-types.xml +++ b/docs/en-US/advanced-zone-network-traffic-types.xml @@ -28,7 +28,7 @@ Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. This network can be isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to provide isolation for each &PRODUCT; account’s network (potentially a large number of VLANs). In a shared guest network, all guest VMs share a single network. Management. When &PRODUCT;’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by &PRODUCT; to perform various tasks in the cloud), and any other component that communicates directly with the &PRODUCT; Management Server. You must configure the IP range for the system VMs to use. Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the &PRODUCT; UI to acquire these IPs to implement NAT between their guest network and the public network, as described in “Acquiring a New IP Address” in the Administration Guide. - Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. &PRODUCT; uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network. + Storage. While labeled "storage" this is specifically about secondary storage, and doesn't affect traffic for primary storage. This includes traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. &PRODUCT; uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network. These traffic types can each be on a separate physical network, or they can be combined with certain restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into making only valid choices. http://git-wip-us.apache.org/repos/asf/cloudstack/blob/4bf22b1a/docs/en-US/basic-zone-network-traffic-types.xml ---------------------------------------------------------------------- diff --git a/docs/en-US/basic-zone-network-traffic-types.xml b/docs/en-US/basic-zone-network-traffic-types.xml index 70789d0..8503736 100644 --- a/docs/en-US/basic-zone-network-traffic-types.xml +++ b/docs/en-US/basic-zone-network-traffic-types.xml @@ -26,10 +26,10 @@ When basic networking is used, there can be only one physical network in the zone. That physical network carries the following traffic types: Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with each other over a network that can be referred to as the guest network. Each pod in a basic zone is a broadcast domain, and therefore each pod has a different IP range for the guest network. The administrator must configure the IP range for each pod. - Management. When &PRODUCT;’s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by &PRODUCT; to perform various tasks in the cloud), and any other component that communicates directly with the &PRODUCT; Management Server. You must configure the IP range for the system VMs to use. + Management. When &PRODUCT;'s internal resources communicate with each other, they generate management traffic. This includes communication between hosts, system VMs (VMs used by &PRODUCT; to perform various tasks in the cloud), and any other component that communicates directly with the &PRODUCT; Management Server. You must configure the IP range for the system VMs to use. We strongly recommend the use of separate NICs for management traffic and guest traffic. Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs must be allocated for this purpose. End users can use the &PRODUCT; UI to acquire these IPs to implement NAT between their guest network and the public network, as described in Acquiring a New IP Address. - Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. &PRODUCT; uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network. + Storage. While labeled "storage" this is specifically about secondary storage, and doesn't affect traffic for primary storage. This includes traffic such as VM templates and snapshots, which is sent between the secondary storage VM and secondary storage servers. &PRODUCT; uses a separate Network Interface Controller (NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on a high bandwidth network allows fast template and snapshot copying. You must configure the IP range to use for the storage network. In a basic network, configuring the physical network is fairly straightforward. In most cases, you only need to configure one guest network to carry traffic that is generated by guest VMs. If you use a NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features, you must also configure a network to carry public traffic. &PRODUCT; takes care of presenting the necessary network configuration steps to you in the UI when you add a new zone.