SPICE failure in Win10 VM -- what listens on port 3128???

MrPete

Active Member
Aug 6, 2021
125
62
33
67
I am trying to get SPICE going for the first time, and failing miserably.
I *think* I've debugged to the following point:
* firewalls are not an issue. I can ping everywhere, can RDP in, can ping, etc.
* I've loaded all of the various bits that need loading AFAIK into local machine, into guest VM. VM hardware config looks right

What I do NOT see:
* No process on the host, nor in the VM, is listening to port 3128
* Therefore, I get no response on any attempt to connect

SO: what SHOULD be listening to 3128???

(And BTW, for at least some sense of better security, is there a way to modify that port?)

THANKS!
 
Hi,
you can use the spiceproxy API call to get a configuration file which can be used by clients like remote-viewer to connect. The ports used for SPICE are 61000+. See the command line of the running kvm process to see which one a specific instance has, e.g. -spice tls-port=61001,addr=127.0.0.1,tls-ciphers=HIGH,seamless-migration=on
 
Hi,
you can use the spiceproxy API call to get a configuration file which can be used by clients like remote-viewer to connect. The ports used for SPICE are 61000+. See the command line of the running kvm process to see which one a specific instance has, e.g. -spice tls-port=61001,addr=127.0.0.1,tls-ciphers=HIGH,seamless-migration=on
Thank you, that helped me get a bit further. Now I understand:
* On PVE, we don't directly connect to the VM at all (eg via VM IP address) but always and only via the host.
* I now see spiceproxy in the host, etc.

I've now run spiceproxy in debug mode to examine why the connection isn't happening. (I am successfully saving a *.vv file from the PVE GUI. The *.vv file content looks good.)

Here's the breakage I see when the connect attempt takes place. This all happens in a fraction of a second, and is repeatable:
worker[3961]: PVE::APIServer::AnyEvent +1792: (eval): ACCEPT FH10 CONN1
worker[3961]: PVE::APIServer::AnyEvent +189: client_do_disconnect: close connection AnyEvent::Handle=HASH(0x5f842b12ffe0)
worker[3961]: PVE::APIServer::AnyEvent +189: client_do_disconnect: CLOSE FH10 CONN0

That's not exactly helpful. Any ideas? It almost sounds like the *client* is giving up immediately :(
QUESTION: Is there a verbose debug flag I can set somewhere, for spiceproxy?
 
Last edited:
I've now run spiceproxy in debug mode to examine why the connection isn't happening. (I am successfully saving a *.vv file from the PVE GUI. The *.vv file content looks good.)
What software did you use to open the .vv file? I'm only aware of remote-viewer to do so.

Here's the breakage I see when the connect attempt takes place. This all happens in a fraction of a second, and is repeatable:
Yes, for me it looks like this:
Code:
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1792: (eval): ACCEPT FH10 CONN1
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1002: (eval): CONNECT 110, pve8a1, 61000
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: AnyEvent::Socket +1052: __ANON__: CONNECTed to 'localhost:61000'
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1792: (eval): ACCEPT FH14 CONN2
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1002: (eval): CONNECT 110, pve8a1, 61000
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: AnyEvent::Socket +1052: __ANON__: CONNECTed to 'localhost:61000'
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1792: (eval): ACCEPT FH16 CONN3
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1792: (eval): ACCEPT FH17 CONN4
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1002: (eval): CONNECT 110, pve8a1, 61000
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: AnyEvent::Socket +1052: __ANON__: CONNECTed to 'localhost:61000'
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1002: (eval): CONNECT 110, pve8a1, 61000
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: AnyEvent::Socket +1052: __ANON__: CONNECTed to 'localhost:61000'

That's not exactly helpful. Any ideas? It almost sounds like the *client* is giving up immediately :(
QUESTION: Is there a verbose debug flag I can set somewhere, for spiceproxy?
I'm not aware of any such flag unfortunately. The (likely) relevant code to debug would be here: https://git.proxmox.com/?p=pve-http...644ab7b8ddf0dc969c2e519c1072c8d;hb=HEAD#l1438
 
  • Like
Reactions: MrPete
What software did you use to open the .vv file? I'm only aware of remote-viewer to do so.


Yes, for me it looks like this:
Code:
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1792: (eval): ACCEPT FH10 CONN1
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1002: (eval): CONNECT 110, pve8a1, 61000
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: AnyEvent::Socket +1052: __ANON__: CONNECTed to 'localhost:61000'
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1792: (eval): ACCEPT FH14 CONN2
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1002: (eval): CONNECT 110, pve8a1, 61000
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: AnyEvent::Socket +1052: __ANON__: CONNECTed to 'localhost:61000'
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1792: (eval): ACCEPT FH16 CONN3
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1792: (eval): ACCEPT FH17 CONN4
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1002: (eval): CONNECT 110, pve8a1, 61000
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: AnyEvent::Socket +1052: __ANON__: CONNECTed to 'localhost:61000'
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: PVE::APIServer::AnyEvent +1002: (eval): CONNECT 110, pve8a1, 61000
Mar 22 12:32:55 pve8a1 spiceproxy[141518]: worker[141518]: AnyEvent::Socket +1052: __ANON__: CONNECTed to 'localhost:61000'


I'm not aware of any such flag unfortunately. The (likely) relevant code to debug would be here: https://git.proxmox.com/?p=pve-http...644ab7b8ddf0dc969c2e519c1072c8d;hb=HEAD#l1438
THANKS!!! I will dig in on that ASAP. :)

(To view the contents of the .vv I used my text/binary file editor. To open for use, I used remote-viewer as recommended.)
 
I found the presenting issue. Sad.
1) HINT: the code nicely pointed by @fiona above is only one aspect. It uses verify_spice_connect_url() and I can't find the actual source for that. (In this module, there's only a stub.)
2) That was a red herring anyway. The REAL issue is not documented anywhere that I can find. Here's the crucial thing you MUST be aware of:

A *.vv file is only valid for about 30 seconds!
This is quite painful in many situations. I sure wish that could be adjusted.
 
I found the presenting issue. Sad.
1) HINT: the code nicely pointed by @fiona above is only one aspect. It uses verify_spice_connect_url() and I can't find the actual source for that. (In this module, there's only a stub.)
2) That was a red herring anyway. The REAL issue is not documented anywhere that I can find. Here's the crucial thing you MUST be aware of:

A *.vv file is only valid for about 30 seconds!
This is quite painful in many situations. I sure wish that could be adjusted.
Please describe your use case in more detail. The idea is that the client requests the file (which also generates a ticket that expires) and opens it immediately. Why not just (re-)request the .vv file right before using it?
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!