Closed Bug 531827 Opened 15 years ago Closed 7 years ago

Unable to start remote console session with VMWare Infrastructure web access

Categories

(Firefox :: Extension Compatibility, defect)

Product:
Firefox
Component:
Extension Compatibility
Version:
3.6 Branch
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: beltzner, Unassigned)

References

Details

(Keywords: relnote, Whiteboard: [need vendor outreach] status: vmware needs to stop using deprecated API)

Attachments

(1 file)

install.rdf
890 bytes, text/plain
Details 
From a beta tester in our Facebook group:

------------

Using VMWare's "Infrastructure web access", I'm unable to start a remote console session. It appears their Remote console plug-in is broken in FF 3.6b4, as it comes back with the error: "Cannot access virtual machine console. The request timed out".

------------

Working on getting more version info out of the reporter, but in the meantime cc'ing some IT folks who are likely to use this software for a confirmation and looping in QA.
Flags: blocking-firefox3.6?
This hasn't worked for me since I moved off Windows.  I don't think anyone here uses the web interface for console access.  

Pulling in RelEng who might use this too.
I've got a Windows machine I can try this on in a bit.
Results:
3.5.5 - WFM
3.6b4 - reproduced
3.6b3 - reproduced

I can binary search through the nightlies and see if I can find out where it broke if it helps.
I think the version I have is: VMWare Server 2.0 122956
Is this an Add-on, or a website?

Ben, if you could do a quick binary regression range, that'd help a lot. Also if it's a website, try flipping your useragent string in about:config.
VMWare server 2.0 uses a browser to manage the VMs, and can be on the same machine as the console runs from.

I've tried flipping useragent to 3.5 to no avail, so I guess it doesn't even check that.
OK, looks like we'll need to get a regression range on this. Anything in the Error Console (Tools > Error Console) on this?

Kev: heads-up!
Keywords: regressionwindow-wanted
Er, I've just realised.. it's a plug-in, which might explain nothing in the error console. FF hasn't complained about incompatibility, though.
Attached file install.rdf — 
So, this is actually a plugin shipped inside of an extension. The install.rdf file sets maxVersion to '3.*'.

There is nothing in the error console.

I'll try to track down a regression range later today.
Just tested in 3.6a1 - doesn't work there either.
Looks like they just need to recompile their binary components for Firefox 3.6; setting the maxVer that way is likely going to make this painful for them.

I don't think that we can block on this, but we should reach out. Do we have contacts at VMWare?
I don't think we can block on this, but we need to get in touch with VMWare and make sure they update this :(
Flags: wanted-firefox3.6+
Flags: blocking-firefox3.6?
Flags: blocking-firefox3.6-
Keywords: relnote
Whiteboard: [need vendor outreach]
I'll try and grab a contact, there.
any updates?
Just installed the Firefox 3.6 Release on windows and hit this same bug with VMware Server 2.0.2 

On the same host and VMware Server 2.0.2 install:
FF 3.5.7 worked
FF 3.6 fails to start VMware Remote Console as per this bug
IE 8 works
FF3.6 Release on Windows 7 Ultimate (64bit) and hit this same bug with VMware ESXi Server 4.0U1 (newest) and vCenter Server 4.0U1 (newest).

worked on FF3.5.7 with same windows above.
Also note Bug 535640 -- some are experiencing a problem whereby the web administration console can't even be reached unless you enable SSLv2.
Does it help if the XPI file is uploaded?
still in search of a regression window from anyone able to reproduce this.
Keywords: qawanted
(In reply to comment #20)
> still in search of a regression window from anyone able to reproduce this.

Based on previous comments, it's between 3.5.7 and 3.6a1. I'll have a look at nightlies in that range and let you know.
Broke between 2009-06-19-04-mozilla-central and 2009-06-20-04-mozilla-central. If that represents a reasonable date query for Bonsai, we get the following.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2009-06-19&maxdate=2009-06-20&cvsroot=%2Fcvsroot

Perhaps Bug 497223, then? That did touch a little networking stuff.

(Note that the tracemonkey range is different, breaking between 2009-06-24-03-tracemonkey and 2009-06-25-03-tracemonkey. I don't really understand the difference between these builds.)
Which includes
52d96051f224	Josh Aas — Remove nsIEventHandler, part of the XPCOM plugin API. b=499329 sr=sicking
782213e33edb	Josh Aas — Remove nsIJRILiveConnectPIPeer and nsIJRILiveConnectPlugin. b=499322 sr=sicking
3c3f41807451	Josh Aas — Remove nsIScriptablePlugin, part of the XPCOM plugin API. b=498164 r/sr=sicking 

VMWare relies on a deprecated interfaces ?
Thanks Greg.

removing keyword bugday. (regressionwindow-wanted is todays bugday topic)
Keywords: regressionwindow-wanted
Has this issue been fixed now? I am having issues with 3.6 and vmware remote console. Plus mozilla doesn't seem to want to work with the itacademy.microsoftelearning.com/eLearning web site either. I really hate to have to use IE just to log on and do my school work. 

I have version 3.6 and the same issue that Dwaine in comment 15 had.If anyone has fixed this please let me know.
(In reply to comment #26)
> Has this issue been fixed now? I am having issues with 3.6 and vmware remote
> console. Plus mozilla doesn't seem to want to work with the
> itacademy.microsoftelearning.com/eLearning web site either. I really hate to
> have to use IE just to log on and do my school work. 
> 
> I have version 3.6 and the same issue that Dwaine in comment 15 had.If anyone
> has fixed this please let me know.

I was having the same problem yesterday (03/13/10).  I cheated a little and rolled back to FF 3.5.8 and was able to run the console.
Official (?) response from VMWare on their forums:
 http://communities.vmware.com/thread/258378
Don't know if this helps: 
When using FF 3.6.x to access the VMware WebConsole (not the Console of the virtual Machine itself!), the connection cannot be established; the connection times out. The log of the VMware Server is:

SSL Handshake on client connection failed: SSL Exception: error:140D9115:SSL...

This happens only with FF 3.6.x, regardless of the OS running on (tried Mac OSX, Linux, Windows XP/Vista). Earlier versions of FF run without any problem. Seems, this is not (only) a problem of the VMware plugin, it also affects the SSL handling of FF 3.6 compared to 3.5
bug is still alive in 3.6.11
1. The referred VMware Remote Console Plugin is an extension which includes a plugin.
2. On Windows 7, the plugin is an executable located in "%APPDATA%\Mozilla\Firefox\Profiles\1nc1d3r.default\extensions\VMwareVMRC@vmware.com\plugins" (location is varied on Windows XP/Linux etc.)
3. The executable "vmware-vmrc.exe" (or +x vmware-vmrc) takes the following parameter to open a VNC protocol console to a VMware's virtual guest:
-h <vmware server/vcenter hostname/ip> 
-u <vmware username> 
-p <vmware password>] 
-M <vmware machine id> | <vmware datastore path>

4. The executable if ran manually (eg: vmware-vmrc.exe -h 1.2.3.4 -u user -p pass -M 123) executes successfully; thus there no issue with the plugin by itself.
5. If an attempt to open the plugin from within FF, the plugin is never executed.
 i. On Windows 7, monitored from Sysinternal's Process Monitor, FF attempts to read the non-existent "HKLM\SOFTWARE\Microsoft\CTF\KnownClasses" registry key. Why?
5. Possibly the issue is how the executable is called (or never called) from within FF and not the plugin itself ?
6. Can anyone point out how does any executable/shell-process being executed/called from within FF anyway ?

More readup on: http://communities.vmware.com/message/999988;jsessionid=A135EF8314A4068012697572DC180568
Per the link in comment #28, this is something VMWare are working on fixing. CC'ing Josh Aas, author of the changes we think caused the issue (comment #23, comment #24).
We removed support for the XPCOM plugin API in Firefox 3.6. I wasn't aware that VMWare used the API or I'd have made an effort to get in touch with them years ago and give them early warning. I recommend that plugin developers monitor the plugin-futures mailing list in order to learn about changes to plugin APIs as early as possible.
Is there any documentations talking about the changes and replacement for this "XPCOM plugin API" for programmers who have no previous knowledge (like me) about it?  Maybe we could apply a "quick and dirty" solution to the XPI package if we have sufficient informations.
With FF4 vSphere Web Access is not working :(
I wanted to see if the bug has been fixed in the 4.0 beta 11 firefox but the problem is worse :
- as long as you query the vmware server (1rst line on the left side), it works
- but if you click on any VM, the right side of the screen becomes empty, even if you click again on the vmware server.
Tested with the 2.0.0 build 122956 version of the vmware server.
Yes, confirmed.

Actually, it's even worse than you described: the right pane is displayed only for the first time you connected to the server.  All successive click gives nothing.  And if you "refresh" the page, nothing except the menu is displayed!
Note that Lab Manager 4.0.2 supports Firefox 3.6, but that earlier versions don't (http://www.vmware.com/support/labmanager40/doc/releasenotes_labmanager402.html#ffsupport), and 4.0.2 doesn't support older versions of the vCenter server (e.g. v2.5. U6). I'm still attempting to get a contact there, but all regular channels haven't been terribly effective, and I'm not sure they'll be inclined to do back-support for older builds.
Whiteboard: [need vendor outreach] → [need vendor outreach] status: vmware needs to stop using deprecated API
Sure that "vmware needs to stop using deprecated API", but we could go further if there's a list of what are dropped/deprecated and what alternatives are proposed to do more or less the same job, as I've said in comment 36.

I'd like to help, but it's not possible for me to do debugging on something I'm not familiar with.  Is there any tool out there to help us debug on Firefox?  I mean, except the "Error console" which is quite limited.
(In reply to comment #41)
> Sure that "vmware needs to stop using deprecated API", but we could go further
> if there's a list of what are dropped/deprecated and what alternatives are
> proposed to do more or less the same job, as I've said in comment 36.

It's more that they have to update their software (which is unlikely given the version it affects), or the users have to update theirs (which costs $).

> I'd like to help, but it's not possible for me to do debugging on something I'm
> not familiar with.  Is there any tool out there to help us debug on Firefox?  I
> mean, except the "Error console" which is quite limited.

IIRC, it's VMWare's blobs needs to be recompiled against the current version. It's not a question of fixing things on Firefox's end, it's VMWare who needs to update their software to maintain compatibility.
fortunatly, there is a workaround :

* on windows, of course, you can use IE

* but on linux, you can execute the vmware plugin directly :
- go to your vmware server (e.g. myvmwareserver) and find the proper xpi, according to your architecture (32 or 64 bytes ; on my installation (redhat), it's here :
/usr/lib/vmware/webAccess/tomcat/apache-tomcat-6.0.16/webapps/ui/plugin/vmware-vmrc-linux-x64.xpi
- send it to your linux client pc (e.g. under /tmp)
- now, on your linux client pc, create somewhere a vmware directory :
  cd /home/myhome
  mkdir vmware
- unzip the xpi file under this new directory :
  cd vmware
  unzip /tmp/vmware-vmrc-linux-x64.xpi
- then, run the executable
  vmware/plugin/vmware-vmrc
- in the connexion window, type :
  host name : myvmwareserver:8333
  and the username and password that you usually give onto the vmware login window inside firefox
- after, choose the virtual machine
- at the end, it opens the console windows
(In reply to comment #42)
> (In reply to comment #41)
> > Sure that "vmware needs to stop using deprecated API", but we could go further
> > if there's a list of what are dropped/deprecated and what alternatives are
> > proposed to do more or less the same job, as I've said in comment 36.
> 
> It's more that they have to update their software (which is unlikely given the
> version it affects), or the users have to update theirs (which costs $).

Exactly that's the problem.  It's almost a certainty that VMWare Server 2 is dead and it's hard to find replacement with heading a deep learning curve and lot of time needed for conversion, we could only rely on volunteers like us to fix thing.  But without the least information of what's changed in the inside of all these API, it's hard to get started.

> IIRC, it's VMWare's blobs needs to be recompiled against the current version.
> It's not a question of fixing things on Firefox's end, it's VMWare who needs to
> update their software to maintain compatibility.

No, I've not asked FF to fix this since I knew there's a API change (cf my comments).  But are you sure the problem is within the "VMWare's blobs" (what do you mean by "blobs"?  Those dll and exe or equivalent in Linux?)  I'm always thinking the problem is situated in some javascript before any of these binaries are called because the error console of FF always shows a lot of warning and errors even before we want to open a console.
(In reply to comment #44)
> dead and it's hard to find replacement with heading a deep learning curve and

Typo error: I meant ".... hard to find replacement withOUT headng a deep learning curve..."
(In reply to comment #43)
> fortunatly, there is a workaround :
> 
> * on windows, of course, you can use IE
> 
> * but on linux, you can execute the vmware plugin directly :
> [snipped]
> - at the end, it opens the console windows

Of course, there's always a workaround, esp if one is techy enough or does a search in the Internet or VMWare forum where you could find lots of workaround.  But I won't qualify that as "fortunate".  I'd rather say it's UNfortunate because you see, all those steps are supposed to be done by the server instead of by end-users.

Think about VMWare servers deployed to hundreds or thousands of companies which has tens of simple end-users.  And now you're basically asking thousands of simple end-users to act like techy guys and do those techy jobs when they need to use VMWare.  Don't you find it ridiculous?

Or look at it in another picture: it's like car-rental service talking to its customers: well, guys, there's a *little* with our cars but *fortunately* there's a workaround.  You just have to change the tires and do this do that in the car engine.

Do you really feel it fortunate if you are one of those end-users?
don't forget that the vmware server is a free and not supported tool provided by vmware, and you might consider it as a proof of concept rather than a production tool

it's like a free software : you use it at your own risk

if a smart guy chooses such a program to deploy on production servers, he has to be very very smart later on, when a problem occurs ; normal people do buy supported software
Let me think about it.... yeah, you are correct.

The same, Firefox and all Mozilla products are free and no supported tool provided by Mozilla.  So, they should be considered as a proof of concept rather than a production tool.  And we are using it at our own risk.

OK, we should say it loud to the whole world to switch back I.E.
you're right on free software

I made a mistake : the vmware server is not a free software like firefox, it's just a freeware like I.E. (because you don't have the sources)

It's exactly what I said : people who use I.E. do that at their own risk, like people who use vmware server
Saying that people using free software are at their own risk is an absolute absurdity.  Come on, we are in the 21st century and this kind of reasoning/mentality should be put inside a museum.  Having good support has nothing to do with being free or not.  Some free software have good support while some paid software, like *cough* Windows, have bad support but they are too essential that it's hard to find alternatives.

Anyway, VMware Server 2 is no longer supported.  It's been replaced by ESXi (once again, which *can* be a free software but support in forum and elsewhere is very good).  In later versions of ESXi, we have EHC (Embedded Host Client) which works well with modern browsers/FF.

For those who still need to run VMware Server 2: you have to use FF 3.5 in side-by-side mode, ie using a special profile for it.  You could read this page (https://blog.andreloker.de/post/2008/06/19/Firefox-2-and-3-side-by-side.aspx) to get the idea how to set it up.  I'm not sure portable version of FF would work although I have never tried it, but I think installing the console plug-in would be challenging.

So, I think it's time to close this bug as "won't fix", unfortunately.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: