Return-Path: X-Original-To: apmail-incubator-cloudstack-users-archive@minotaur.apache.org Delivered-To: apmail-incubator-cloudstack-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9139CC31D for ; Fri, 22 Jun 2012 11:01:00 +0000 (UTC) Received: (qmail 92077 invoked by uid 500); 22 Jun 2012 11:00:59 -0000 Delivered-To: apmail-incubator-cloudstack-users-archive@incubator.apache.org Received: (qmail 91917 invoked by uid 500); 22 Jun 2012 11:00:59 -0000 Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: cloudstack-users@incubator.apache.org Delivered-To: mailing list cloudstack-users@incubator.apache.org Received: (qmail 91868 invoked by uid 99); 22 Jun 2012 11:00:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2012 11:00:57 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of geoff.higginbottom@shapeblue.com designates 216.32.180.31 as permitted sender) Received: from [216.32.180.31] (HELO va3outboundpool.messaging.microsoft.com) (216.32.180.31) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 22 Jun 2012 11:00:48 +0000 Received: from mail167-va3-R.bigfish.com (10.7.14.244) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.23; Fri, 22 Jun 2012 10:58:57 +0000 Received: from mail167-va3 (localhost [127.0.0.1]) by mail167-va3-R.bigfish.com (Postfix) with ESMTP id 73F473600BB for ; Fri, 22 Jun 2012 10:58:57 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.253.197;KIP:(null);UIP:(null);IPV:NLI;H:DBXPRD0710HT001.eurprd07.prod.outlook.com;RD:none;EFVD:NLI X-SpamScore: 0 X-BigFish: PS0(zzc85fhzz1202hzzz2fh2a8h668h839hd25hf0ah) Received-SPF: pass (mail167-va3: domain of shapeblue.com designates 157.56.253.197 as permitted sender) client-ip=157.56.253.197; envelope-from=geoff.higginbottom@shapeblue.com; helo=DBXPRD0710HT001.eurprd07.prod.outlook.com ;.outlook.com ; Received: from mail167-va3 (localhost.localdomain [127.0.0.1]) by mail167-va3 (MessageSwitch) id 1340362734191525_16557; Fri, 22 Jun 2012 10:58:54 +0000 (UTC) Received: from VA3EHSMHS020.bigfish.com (unknown [10.7.14.240]) by mail167-va3.bigfish.com (Postfix) with ESMTP id 2B72D200F9 for ; Fri, 22 Jun 2012 10:58:54 +0000 (UTC) Received: from DBXPRD0710HT001.eurprd07.prod.outlook.com (157.56.253.197) by VA3EHSMHS020.bigfish.com (10.7.99.30) with Microsoft SMTP Server (TLS) id 14.1.225.23; Fri, 22 Jun 2012 10:58:53 +0000 Received: from DBXPRD0710MB371.eurprd07.prod.outlook.com ([169.254.8.123]) by DBXPRD0710HT001.eurprd07.prod.outlook.com ([10.255.79.164]) with mapi id 14.16.0164.004; Fri, 22 Jun 2012 11:00:20 +0000 From: Geoff Higginbottom To: "cloudstack-users@incubator.apache.org" Subject: Storage Networks XenServer Thread-Topic: Storage Networks XenServer Thread-Index: Ac1QZhSxwer8LEIUTfaqPMTvPzjRjw== Date: Fri, 22 Jun 2012 11:00:19 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.212.90.180] Content-Type: multipart/alternative; boundary="_000_A45D051ADB9CE845A987E1A3D6579BAA1D4F6354DBXPRD0710MB371_" MIME-Version: 1.0 X-OriginatorOrg: shapeblue.com X-Virus-Checked: Checked by ClamAV on apache.org --_000_A45D051ADB9CE845A987E1A3D6579BAA1D4F6354DBXPRD0710MB371_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi I have been trying to get a system up and running using XenServer 6.0.2 wit= h multiple physical networks, with one nic dedicated to Storage. There seems to be a lot of contradictory info regarding the use of the stor= age network, and whether it is for Primary or Secondary storage. The latest admin guide for 3.0.3 states the following Storage Network Topology Requirements The secondary storage NFS export is mounted by the secondary storage VM. Se= condary storage traffic goes over the management traffic network, even if t= here is a separate storage network. Primary storage traffic goes over the s= torage network, if available. If you choose to place secondary storage NFS = servers on the storage network, you must make sure there is a route from th= e management traffic network to the storage network. And Separate Storage Network for XenServer (Optional) You can optionally set up a separate storage network. This should be done f= irst on the host, before implementing the bonding steps below. This can be = done using one or two available NICs. With two NICs bonding may be done as = above. It is the administrator's responsibility to set up a separate storag= e network. Give the storage network a different name-label than what will be given for= other networks. For the separate storage network to work correctly, it must be the only int= erface that can ping the primary storage device's IP address. For example, = if eth0 is the management network NIC, ping -I eth0 must fail. In all deployments, secondary storage devices must be pinga= ble from the management network NIC or bond. If a secondary storage device = has been placed on the storage network, it must also be pingable via the st= orage network NIC or bond on the hosts as well. I think it is pretty clear that a "Storage Network" in CloudStack is for Pr= imary Storage, but can optionally be used for Secondary Storage. So I have a test system with single XenServer 6.0.2 Host, with 4 physical N= ICs, and each NIC is assigned a role with the appropriate traffic label eg NIC 0: Management NIC 1: Guest NIC 2: Public NIC 3: Storage The CS Management Server, Host and Secondary Storage are all on the 192.168= .1.0/24 address range with no VLAN tagging The Primary Storage is on the 172.16.0.0/24 address range with no VLAN tagg= ing Deploying a new Zone works OK, and the System VMs (SSVM and CP) come on lin= e, however uploading templates or ISOs fails. When I log onto the SSVM and try and ping the Secondary Storage IP (192.168= .1.100) it fails as there is a ROUTE forcing the traffic over the Storage N= etwork NIC which is a completely different physical network rung on IP Rang= e 172.16.0.0. If I manually delete the ROUTE then the SSVM can ping the S= econdary Storage and the Templates and ISOs upload correctly. Can someone clarify how we should be using the Storage Network ideally with= some detailed examples including IPs Thanks Geoff ShapeBlue provides a range of strategic and technical consulting and implem= entation services to help IT Service Providers and Enterprises to build a t= rue IaaS compute cloud. ShapeBlue's expertise, combined with CloudStack tec= hnology, allows IT Service Providers and Enterprises to deliver true, utili= ty based, IaaS to the customer or end-user. ________________________________ This email and any attachments to it may be confidential and are intended s= olely for the use of the individual to whom it is addressed. Any views or o= pinions expressed are solely those of the author and do not necessarily rep= resent those of Shape Blue Ltd. If you are not the intended recipient of th= is email, you must neither take any action based upon its contents, nor cop= y or show it to anyone. Please contact the sender if you believe you have r= eceived this email in error. Shape Blue Ltd is a company incorporated in En= gland & Wales. --_000_A45D051ADB9CE845A987E1A3D6579BAA1D4F6354DBXPRD0710MB371_--