Not 100% positive, but recall 2960x QoS is much like 3560/3750 QoS. If so, it's much "weaker" than on many platforms that support MQC QoS, like ISRs. I.e. unsure "hierarchical" policies, or even egress policies are supported. Shaping may be supported per hardware egress queue and/or or the physical interface as a whole, neither though, I believe, defined in a policy, but rather in MLS commands.
Also, don't recall a 2960x can host a tunnel, although it can carry tunnel traffic.
Also, when working with both tunnel traffic (but not at the tunnel interface) the pre-classify command might be needed, but that too, I recall, isn't supported on a 2960x (in would also need to be on the device hosting the tunnel interface).
For QoS purposes, yes when downstream bandwidth is less then the interface you're configuring QoS for, intending to QoS "manage" the downstream bottleneck, generally you'll want to shape for the bottleneck's bandwidth and use a child policy to manage the bottleneck's bandwidth as desired.
Normally, QoS cannot "see" into tunnel encapsulated packets, so in such a situation you cannot "treat" those packet's differently based on their contents. In your case, if the tunnel's packet's are strictly VoIP packets, then you can treat them as as VoIP vs. all the other traffic. However you won't be able to "see" the difference VoIP bearer packets and VoIP control packets. BTW, by default, Cisco platforms do copy a packet's original IP ToS to the encapsulated packet's ToS. This might be used, if available.
BTW, I'm unsure how to interpret your diagram's bandwidth usage. What I think you want to do, likely either isn't optimal and/or not possible on a 2960x.
