I apologize so many puzzling terminologies here, to your surprise, the storage network in CloudStack is currently for secondary storage. http://wiki.cloudstack.org/display/DesignDocs/Storage+network+in+Acton has a short explanation. To people's intuition, I quite understand the storage network should imply primary storage, we used confusing notion in this part. As far as I know, CloudStack hasn't been capable of leveraging dedicated nic on host for primary storage.
> -----Original Message----- > From: Geoff Higginbottom [mailto:[email protected]] > Sent: Friday, June 22, 2012 4:00 AM > To: [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.
