Mailing-List: contact cloudstack-users-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cloudstack-users@incubator.apache.org
Received-SPF: unknown
 amxa:i11-www2.idea11.com.auinclude:_spf.getharvest.com?all
 (athena.apache.org: encountered unrecognized mechanism during SPF processing
 of domain of jkahn@idea11.com.au)
From: James Kahn <jkahn@idea11.com.au>
To: "cloudstack-users@incubator.apache.org"
	<cloudstack-users@incubator.apache.org>
Subject: Re: Storage Networks XenServer
Thread-Topic: Storage Networks XenServer
Thread-Index: Ac1QZhSxwer8LEIUTfaqPMTvPzjRjwAX8LsA
Date: Fri, 22 Jun 2012 12:24:53 +0000
Message-ID: <CC0AA05B.1D5BF%jkahn@idea11.com.au>
In-Reply-To: 
 <A45D051ADB9CE845A987E1A3D6579BAA1D4F6354@DBXPRD0710MB371.eurprd07.prod.outlook.com>
Accept-Language: en-AU, en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/14.2.2.120421
Content-Type: text/plain; charset="us-ascii"
Content-ID: <A12D8634617AAE48B6F600A5BC45E0D0@apcprd06.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

Hi Geoff,

We experienced the same and settled for adding a route between the storage
and management networks on L3 switches.

I agree that ideally secondary storage should be able to be isolated to
the management network only to ensure primary storage performance.

JK.


-----Original Message-----
From: Geoff Higginbottom <geoff.higginbottom@shapeblue.com>
Reply-To: "cloudstack-users@incubator.apache.org"
<cloudstack-users@incubator.apache.org>
Date: Friday, 22 June 2012 9:00 PM
To: "cloudstack-users@incubator.apache.org"
<cloudstack-users@incubator.apache.org>
Subject: Storage Networks XenServer

>Hi
>
>I have been trying to get a system up and running using XenServer 6.0.2
>with multiple physical networks, with one nic dedicated to Storage.
>
>There seems to be a lot of contradictory info regarding the use of the
>storage 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.
>Secondary storage traffic goes over the management traffic network, even
>if there is a separate storage network. Primary storage traffic goes over
>the storage 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 the 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
>first 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 storage 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
>interface that can ping the primary storage device's IP address. For
>example, if eth0 is the management network NIC, ping -I eth0 <primary
>storage device IP> must fail. In all deployments, secondary storage
>devices must be pingable 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 storage network NIC or bond on the hosts as well.
>
>
>I think it is pretty clear that a "Storage Network" in CloudStack is for
>Primary 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
>NICs, 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
>tagging
>
>Deploying a new Zone works OK, and the System VMs (SSVM and CP) come on
>line, 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 Network NIC which is a completely different physical network rung
>on IP Range 172.16.0.0.   If I manually delete the ROUTE then the SSVM
>can ping the Secondary 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
>implementation services to help IT Service Providers and Enterprises to
>build a true IaaS compute cloud. ShapeBlue's expertise, combined with
>CloudStack technology, allows IT Service Providers and Enterprises to
>deliver true, utility based, IaaS to the customer or end-user.
>
>________________________________
>
>This email and any attachments to it may be confidential and are intended
>solely for the use of the individual to whom it is addressed. Any views
>or opinions expressed are solely those of the author and do not
>necessarily represent those of Shape Blue Ltd. If you are not the
>intended recipient of this email, you must neither take any action based
>upon its contents, nor copy or show it to anyone. Please contact the
>sender if you believe you have received this email in error. Shape Blue
>Ltd is a company incorporated in England & Wales.