Console woes over Firewall.

[amills]

Hi all. I've got an issue where my ESX3 server is in a data center so I can SSH directly to the box, but I have to set up port forwarding to do anything like remote console. This is causing a problem because when I attempt to launch a console on a newly created VM, I get an error.

Is there a way to set up VNC on these VMs (a la VMWare Server) or some other mechanism to get a remote console? This problem is stopping me in my tracks.

Thanks.

[Dave_Mishchenko]

If you have a Windows box in the data center you could install the VI client on it and then just remote desktop to the Windows box. Performance of the remote console will probably be better as well.

[amills]

Unfortunately, I don't have a windows box to do this with. Is there any other way or is port forwarding a remote console session (or creating VNC) just not possible?

[Dave_Mishchenko]

Since you're able to connect directly to the ESX host with SSH can you do the same for port 903? That's the port for remote console and all remote console sessions will go directly to the ESX host service console port and not to the IP of the VMs.

[amills]

At the data center the server is firewalled. I can, ssh, but other ports are blocked aside from 80 and 443.

To get the VI console working, I ssh to the server, then port forward 902 to localhost (I'm using PuTTY). This allows VI console connections, but when I try to get a console to the VM, it tries to connect to the actual IP of the ESX server which, of course, is blocked.

What I'd like to have is the ability to set up VNC on the VM in the .vmx file and then use port forwarding to connect.

I take it this isn't an option on ESX. But Is there any other way to get a console on a VM without either setting up a VI client in my data center or poking a hole in the firewall? That seems very kludgy to me.

[Texiwill]

Hello,

We had that same problem, and after months of trying to get port forwards, complex host tables and dns servers, we opted for trying a VPN solution that eventually worked but required too many host tables and dns server changes to be of much use. There is another option that works fairly well:

You could create a VM running Windows, put it on your admin network and use RDP/VNC to access the VM and run the VI Client from there. This would work as its part of your 'network'. It is about the only thing we could get working when trying to do exactly what you are doing.

If you are outside your corporate firewall a VPN that takes over your network connection, sets up the proper DNS/Host tables would also work.

Best regards,

Edward

[wila]

Sounds like a known issue, read here for the solution, basically it comes down to adding a single line to the /etc/vmware/config file.

http://www.vmware.com/community/click.jspa?searchID=4463357&messageID=674506

[Texiwill]

Hello,

We tried that with no success. We thought that was very strange ourselves and developed a slightly different approach as we stated for remote work. This way our laptops/remote computers can run what we want and not forced to run windows.

Best regards,

Edward

[amills]

Man, that's a poor fix for a product that costs a few grand. The more I play with ESX, the more I like VMWare Server.

Not being able to connect gracefully through a firewall, or with Linux, is simply unacceptable.

[Texiwill]

Hello,

Actually, using a VM to get the connection you need to VC is very graceful. The reason being is that you no longer need to worry about the OS from where you are coming as long as SSH runs all is well. In addition, I have used many a VPN, and always had a remote VM for administrative functions. This sped things up quite a bit, why run time consuming things over a sometimes bad remote connection. Specifically, it helps when doing this if you are suddenly disconnected in the middle of setting up vMotion or anything else. You just log back in to the VM using RDP and pick up where you left off. No need to restart your work. I say being able to use a VM in this fashion is very graceful and prudent over slow links. I telecommuted for 15 years and this was the best way to work with ESX.

However, this is really only a problem if you connect to VC, if you connect direct to the ESX server then all should work as expected.

On a personal note, I am not sure I would trust my production VMs to VMware Server. But I think that is a religious debate.

Best regards,

Edward

[wila]

Well it works for me without a hitch on several ESX hosts. The approach you talk about on using a VM for providing RDP support is of course better when you need to support multiple users or if you need to connect to VC regularly for maintenance.

Especially the additional :resume: functionality could be handy as you've explained already above.

But to point out, the work around does work. Although i'm not sure why it didn't work for you.

[Texiwill]

Hello,

Well, I wish I knew, but it did lead me down another path that proved to work even better. We now have a low-bandwidth solution that is secure and works 100% of the time and provides a recovery method. And an easy to implement solution as well (well easy for the users, the main administration is still a little tricky).

Adversity breeds ideas \*grin*

Best regards,

Edward

[amills]

"Actually, using a VM to get the connection you need to VC is very graceful"

The only problem I see is that it's a bit circular. You have to have a VM to get connected to create a VM. In my case, I've got a number of VMWare Server VM's so I can do this - but it's kludgy since all those VMs are supposed to be dedicated test/production hardware.

I'd prefer to be able to simple SSH tunneling, but that's not to be 😕

Thanks for the help!

[amills]

wila - your suggestion fixed my problem. I thought I'd tried it earlier, but aparently not. Thanks a lot!!! I can now port forward from outside the network.

[wila]

Ah good to hear it helped. Well now, let me warn you that you might have to re-add that same line again after installing patches.