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 <[email protected]> Reply-To: "[email protected]" <[email protected]> Date: Friday, 22 June 2012 9:00 PM To: "[email protected]" <[email protected]> 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.
