When I try to access Virtual Center's web access from a remote machine via a url containing the fqdn of the machine, tomcat is changing the url to use the short name of the Windows machine instead of the fqdn. The result is a dns lookup failure. For example, I navigate to https://virtualcenter.domain.com/ui and tomcat does a redirect to https://virtualcenter/ui, which isn't a valid name in our dns. How do I configure tomcat to not change the url and continue to use the fqdn that I'm starting with? I've been struggling with this for a while and would appreciate any help I can get. Thanks.
I had the same problem. Seems to me like the VC web access really wants to use WINS for name resolution. Even going to just the IP address it failed because of the rewrite.
I had to create a DNS name that matched the server name and then enable dns suffixing. It worked after doing that.
You could put the hostname and ips on your c:\windows\system32\drivers\etc\hosts file
That's great if you only use that single pc. And, if you only use that one PC why not use the fat client?
The nature of web access is so you can access the console from anywhere. Given that, hard-coding it in the host file is not a good solution.
It seems to me that you can put an alias for the DNS entries (not fqdn).
So this is the solution for a DNS only network.
I will have people using web access from machines I don't directly control, which rules out making changes to the hosts file. I'm hoping to find a solution to the real problem, which is tomcat rewriting the URL. I figured there was a configuration option for tomcat somewhere to tell it what the fqdn of the server is, but I haven't been able to find it yet.
Did you try putting changing the hosts file in the Web access server?
VMWare tomcat is not a standard tomcat so I'm not sure you can configure it at your pleasure.
It seems to me that you can put an alias for the DNS
entries (not fqdn).
So this is the solution for a DNS only network.
You can't really do that. An alias to virtualcenter.domain.com, would be itself.
Are the clients not setup to append their root domain when performing lookups? Or is the problem that you have multiple domains and their search paths don't include the other subdomains (i.e. users in users.domain.com can't find virtualcenter.servers.domain.com)? If that's the case, then an alias virtualcenter.domain.com -> virtualcenter.servers.domain.com should work.
Anyway, if i reference my own "virtualcenter.resource.domain.com" the link presented in the welcome screen includes the FQDN, not the shortname. What version of VC are you running? Patch 2?
Scratch that... I see that when I actually CLICK on the link, it does drop it down to the shortname! You'll need to file a SR. That should not happen, and I doubt there's a way to hack this to work. I've looked at trying to mod that page before.
In the meantime, you can have you users skip the welcome page by providing them a link directly to https://server.domain.com/ui
The FQDN remains intact when accessing the url directly.
Message was edited by:
hicksj
I will have machines from different subdomains using webaccess, so DNS isn't really a solution for me. I will file an SR and see what VMWare says. It sounds like the solution isn't going to be as easy as I was hoping it would be. Thanks for everyones suggestions.
Different subdomains do not are a problem if using a DNS on root domain.
But I suppose this is not the case.
Don't you like Ip address access?
it works fine
Actually, it fails using just the IP address as well. The re-write is a problem.
Just to remember that you must provide a routing to the VC server too.
Can you telnet VC on 443?
I think I'm losing my mind. I swear I tried this before and it didn't work. What I'm seeing now is that if I use https://fqdn and click on the webaccess link, it works. It's only if I don't connect to the main page using SSL (http://fdqn) that the rewrite happens because it wants to force SSL for webaccess and breaks the URL. I'm still going to file a SR, but this is behavior I can live with. I'll just block port 80 and force everyone to use SSL to connect for now. I'm not sure how I missed this when I was looking at this before.
Well I think you have only a browser's settings problem.
Look in IE at security tab do you have the flag require https on your trusted sites?
Message was edited by:
masaki
Is http://fdqn in your trusted sites?
I'm using Firefox, not IE.
Look at Tools->Options->Advanced
play with the settings. See under Revocations lists and so on..