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
