Have you also reviewed using One Connect Profile K7964 and for debug of cookie K5714?
Also when you were using source address persistance on the Second VIP did see what is the Load Balancing method on the first VIP? Also because there could be a proxy before the first VIP this could explain why the first VIP may select just one pool member more than the other and the the source address persistance of the second VIP may again affect you. You may also test changing the persistance of the first VIP if does SSL decryption to another cookie persistance with a cookie with different name of SSL persistance if there is no decryption:
On both VIPs there is a round-robin, the load is distributed ok but when it comes to 2nd VIP problem starts because of source persistence VIP1 has 2 members in the pool and only 2 members are being utilized from VIP2. Thank you for links i will take a look
Ok, please test and mention the results except the things I already mentioned, you can also test CARP persistance on the second VIP. As the example below shows using the XFF header that the first VIP can inject, so that the persistance to be based on real client IP addresses rather than the first VIP pool members.