A VSX LAG (also initially referred to Multi-Chassis LAG or MCLAG before Multi-Chassis was renamed into VSX) is a LAG that is "spead across" VSX members having member interfaces belonging to both of them...even if it is singularly configured (simmetrically, I add) on each of them.
A traditional LAG instead references to member interfaces of a singular switch (or of many of them if in presence of VSF/IRF cluster).
Say you have Aruba 8320 node 1 (VSX Primary role) and Aruba 8320 node 2 (VSX Secondary role)...then an example of VSX LAG - we are going to call it "lag1" necessarily on both nodes - would include (and would be defined by): lag1 with member interfaces 1/1/1 - 1/1/4 on node 1 and lag1 with member interfaces 1/1/1 - 1/1/4 on node 2 ...for a (maximum) grand total of 8 member interfaces...those 8 interfaces are seen as member of an unique ports trunk by any upstream/downstream LACP LAG capable devices...this even if the LACP LAG on them will be not co-termininus on the same VSX node (that's the purpose of VSX LAGs...overcoming this essential requirement).
I don't recall it is a restriction but, for simmetry (and to keep things simple to troubleshoot IMHO), I think it's better to use simmetrical member interfaces on both VSX nodes for VSX LAGs...at least this is what I've done: for sure you should at least involve the same number of interfaces on both VSX members...avoiding a VSX LAG with an odd number of total member interfaces (use always 2 and multiple of 2, up to 4 per node...8 at most in total per VSX LAG...so 1+1, 2+2, 3+3 or 4+4).
Traditional LAG, as said above, are "simple" ports aggregation (Non Protocol or LACP) residing on a single switch.