Hi Jithin, Thanks for the response, it really helped clarify the situation.
Kind regards, Jeroen Kleijer On Wed, Feb 12, 2025 at 5:55 AM Jithin Raju <jithin.r...@shapeblue.com> wrote: > Hi Jeroen, > > SSVM is used for copying the template from secondary to primary storage > for ESXi with CloudStack. For KVM and XenServer/XCP-NG, the copy is done > via hosts. CloudStack expects that hosts can mount the secondary storage > for these hypervisors. > > Storage traffic type is an optional group of pod-scoped networks you can > define in a zone for plugging a vNIC to the SSVM with that IP and VLAN so > that it will access the secondary storage using that dedicated network. If > this is not defined, it will expect access to the secondary storage via the > management network. Whether the storage is accessed within the same L2 or > it has to cross gateways is something we have to decide. Primary storage > can be on the same network or a different network, but it is not defined in > CloudStack configurations. CloudStack expects that the hypervisor has > access to the primary storage. > > -Jithin > > From: Jeroen Kleijer <jeroen.klei...@gmail.com> > Date: Tuesday, 11 February 2025 at 1:55 PM > To: users@cloudstack.apache.org <users@cloudstack.apache.org> > Subject: Private Storage (L2) LAN + SSVM > Hi all, > > TL;DR: > Who does the copying of the template from the secondary storage pool to the > primary storage pool? Is this the responsibility of the Storage VM? Or does > the Storage VM tell a hypervisor to do this? (we're running 4.19.1.2) > > > For those that have a bit more time: > I'm confused with a particular concept here. > We have an acceptance environment where we have implemented several > different networks according to Apache CloudStack recommendations: > - we have a dedicated (L3) management network where our Apache CloudStack > VMs reside (db + mgt vms) > - we have a dedicated (L3) hypervisor network where our hypervisors reside > - we have a dedicated (L2) storage network where our primary storage pool > resides > > Our secondary storage pool resides on a different L3 network and our > hypervisors obviously have an address in the L2 storage network as well. > During installation we configured our Storage VM to have an IP address in > the (L2) storage network as well and thought this was required in order to > be able to templates from the secondary storage pool (which resides on an > L3 network) to the primary storage pool (which resides on the L2 network). > > This all worked beautifully but when we implemented the same design in > production, we had issues with the Storage VM being on and off again > unavailable up to the point that it just wasn't responding properly. > Looking into the console, we noticed that a route was added that was > causing the issue and the only way to properly get rid of it was to remove > the Storage IP range that was assigned for our Storage VM. We deleted the > Storage VM, it got created again though this time without an IP address in > the L2 primary storage network and lo and behold, everything worked as it > should. We're able to upload templates which in all isn't strange since our > secondary storage pool resides on an L3 network and is reachable from > (almost) anywhere. What is strange to us is that it's able to copy > templates from the secondary storage pool to the primary storage pool when > the Storage VM has no access (IP address) in the L2 Storage network. We > checked through the console of the Storage VM and it cannot reach or mount > any of the L2 Primary Storage pools. > > So when you create a new VM, is it the Storage VM that does the copying of > a template from the Secondary storage pool to the primary storage pool (and > thus should have an IP address in any L2 network) or does it tell the > hypervisor to do that for it? If so, why would the Storage VM need an IP > address in an L2 storage network? > > Kind regards, > > Jeroen Kleijer > > > >
