cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Kahn <>
Subject Re: Storage Networks XenServer
Date Fri, 22 Jun 2012 12:24:53 GMT
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.


-----Original Message-----
From: Geoff Higginbottom <>
Reply-To: ""
Date: Friday, 22 June 2012 9:00 PM
To: ""
Subject: Storage Networks XenServer

>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.
>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
>NIC 0: Management
>NIC 1: Guest
>NIC 2: Public
>NIC 3: Storage
>The CS Management Server, Host and Secondary Storage are all on the
> address range with no VLAN tagging
>The Primary Storage is on the address range with no VLAN
>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
>( 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   If I manually delete the ROUTE then the SSVM
>can ping the Secondary Storage and the Templates and ISOs upload
>Can someone clarify how we should be using the Storage Network ideally
>with some detailed examples including IPs
>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.

View raw message