We have the same issue here. The VIP doesn't work with the same issues you are seeing and you also can no longer connect to the real server addresses because you have to remove the SPNs for those in order to upgrade to 10.1.
I'd just like to add we are looking into the load balancing of the PersOps website whilst using a NLB. If you haven't already could you raise a support case and provide your web.config file from the PWCAPI Web Site as well as a set of IIS logs showing the failed requests.
I have raised the support case and already working with engineer on logs..
I will update here once we conclude on this.
I have found that if I connect with the IP, rather than the FQDN of the VIP it does at least prompt for creds and accepts them.
What load balancer are you using? We have Brocade.
Though I'd check in on this issue. In an isolated environment I set this up successfully without too much pain, however I appreciate live environments are much more complex.
Generally you want to use Kerberos for authentication so you will need to ensure your SPN's are set correctly. e.g.
where pops.vapp.local is my NLB address.
If this is setup correctly then Kerberos should be used as the primary authentication mechanism and I would expect it to connect successfully upon entering valid credentials to the site. If Kerberos is failing then there is likely something wrong in this area. I would expect the systems to fall back to NTLM, however it may be the case this is failing as well., which would result in a constant prompt being displayed. A web debugger (such as Fiddler, for example), is great at troubleshooting these types of issues.
If the IP address has been successful in connecting then this will have auth'd over NTLM, so you should be ok on that front.
Out of interest do your IIS logs show a connecting user through the NLB or has it been stripped from the request?