Providing VM Remote Consoles over the public internet

Hi everyone,

I’m just wondering what people are doing about providing console access for tenants via the public internet.

Our situation - and I doubt this is unusual for a service provider - is that we have a number of VMware vSphere environments sitting behind ManageIQ. ManageIQ’s portal is exposed to the internet via HTTPS, but the vSphere environments are not.

I’m finding that the VMRC console is not actually being proxied by ManageIQ, it seems that ManageIQ is brokering the connection and passing the client VMRC plugin on to vCenter - at which point the connection fails, of course, as the vCenter servers are not exposed to the internet.

We are resistant to trying to proxy a VNC connection, as this would mean modifying a large number of existing customer virtual machines, incurring an outage on each, and from what I gather, the situation would be the same - the connections would be brokered, not proxied.

We could always set up an SSL VPN tunnel, but then the customer would have to log in to the VPN, and then log in again to ManageIQ, which seems awkward and unfriendly.

In this situation, what approaches are other ManageIQ users taking to deliver console access? Does the HTML5 console work in this situation? Are people using VPN & a single sign-on approch. Curious to see what others are doing in this regard.

1 Like

The HTML5 consoles for VMware and RHEVM do the proxying for you. ManageIQ sets up a proxy that proxies the VNC through websocket w/ SSL support. It’s done on a separate port for each connection for now so you have to open a port range starting at 5900 on your firewall. But yes, you can have only that single machine exposed.

So this might be a solution for you. However the HTML5 VNC implementation is new to the product and the client is far from perfect.

Did you get an traction on this topic?

This is something that has been a issue for sometime and I am surprised no “fling” to retro fit vCloud Directors VM console proxy can be found.

Nope. The present state of affairs from Red Hat support for CloudForms is as stated above. HTML5 isn’t going to cut it for the vast majority of vSphere shops for obvious reasons. I totally agree with you regarding the need to get this addressed, and I too am surprised this isn’t higher on the agenda for the ManageIQ / CloudForms engineering teams.

Making remote consoles available via the Internet in a secure manner really should be a high priority for any Cloud Management Platform like this. While I can understand that RHEV and OpenStack ought to be first cab of the rank for a Red Hat project like CloudForms, the reality is the lion’s share of enterprise private / hybrid clouds are deployed on VMware products today, including many niche iaas cloud service providers, which is a fair chunk of the market ManageIQ and CloudForms is aimed at. I do hope that a reverse-proxy solution of some kind for VMRC (either built in or vCloud retro-fit) will be given some priority.

Hello Stephen,

I think everybody would agree this is an important feature. If you are a Red Hat CloudForms customer then please contact your sales team. We have a process for prioritizing customer requests. Red Hat’s contributions to ManageIQ are all driven by our customers but we need to know about it. Also feel free to email me at gjansen at redhat.

If you are using the free version of ManageIQ, then is there a way in which your organization could contribute support for this? ManageIQ is an open community and we really want to encourage people and companies/organizations getting involved.


Hi Geert,

No, we aren’t using the free version, we are a CloudForms shop. I’ll take your advice and see if our sales team can help us get traction for this building this feature into CloudForms.

Though I’d love to be able to offer some contribution to the ManageIQ product, we don’t have a development function in-house at present, so unfortunately we aren’t in a position to offer that. Maybe as I skill up in Ruby through the course of this project I may be able to get involved to some degree, but right now, I’m a bit too n00b-ish to be a valuable contributor to the upstream project. :slight_smile:

Just a quick update for the sake of product confidence.

We are in communication with our Red Hat account team in relation to our specific difficulties with providing consoles within the constraints of our network topolgy and security requirements. We have had an opportunity to discuss our needs in detail with the development engineers, and there is traction building on addressing this issue in a future release.

If you are a customer with a similar need for providing secure console access in NAT environment that challenges the existing architecture, please raise your hand with your Red Hat account team and let them know it’s a priority for you also.

I’m very encouraged by the dialogue we have had both with ManageIQ development and Red Hat, and we are eagerly looking forward to the next step. Thanks to all involved, and good luck with your efforts on this issue.

1 Like

Not a fantastic work around, but having vCenter accessible by FQDN ( same name for internal and external ) over the net via HTTPs, means we can launch VMRC consoles from the also publicly accessible ManageIQ.

Again you still have the whole NPAPI issue with chrome, but as an interim fix and most of all avoiding the VNC re-config on every VM seemed a good middle ground.

Clients do need to install the VMRC plugin, but we only have a handful that really needed console access.

Hi Cloudmonkey

Yes indeed.

Unfortunately, it’s not suitable for our customer base, which is extremely risk averse with regard to infrastructure access from the public internet.

This is going to be very important for us as well. I created a case pointing back to this discussion as an RFE and throwing our hats into the ring. I’ll also bring it up with our sales team and CF Product Management.

Hi, do you have any answer from sales or technical team ?

Hi Stephen, did you finally find a solution, i am not able to proxify the vmrc console trough reverse proxy.