Hi Andrew, Thanks for the reply. Quoting "Andrew Lau" <andrew@andrewklau.com>:
Just install squid proxy and port forward the 3128 port through your firewall you should be all good.
Is squid installed on your oVirt box or is it on your firewall? Or did ypu srtup a seperate box ad the proxy? What you post above suggests you installed it in the oVirt machine?
Here's a quick snippet from my notes: [snip]
engine-config -s SpiceProxyDefault=http://public_ip_address:3128/
Ah, so the IP I put is the *public* IP on the firewall (or at least the one I am connecting to), and not the private IP of the machine Squid is installed on? -Alan
On Sat, Feb 8, 2014 at 9:11 AM, Alan Murrell <lists@murrell.ca> wrote:
Hi Andrew,
Thanks for the reply.
Quoting "Andrew Lau" <andrew@andrewklau.com>:
Just install squid proxy and port forward the 3128 port through your
firewall you should be all good.
Is squid installed on your oVirt box or is it on your firewall? Or did ypu srtup a seperate box ad the proxy? What you post above suggests you installed it in the oVirt machine?
Yup, I install squid on the oVirt engine as it was easier to setup and configure. No point setting up a dedicated box just for the spice proxy unless you need some strict policies.
Here's a quick snippet from my notes:
[snip]
btw the 172.16.0/24 addresses are the oVirt hosts.
engine-config -s SpiceProxyDefault=http://public_ip_address:3128/
Ah, so the IP I put is the *public* IP on the firewall (or at least the one I am connecting to), and not the private IP of the machine Squid is installed on?
Yup, this is the public IP address on the firewall.
-Alan
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
I followed your notes, installing Squid on my oVirt server (I have an all-in-one installation). I set a port forward on our firewall for port 3128 to my oVirt server. I logged into the User Portal and tried connecting to the console, but I get "Could not connect to graphic server (null)". Not sure if I have overlooked something? -Alan
Lots of variables here: - Can you connect to squid from your browser? - Did you modify the squid.conf to match your setup? (dst addresses, etc). - iptables? - restarted engine? - If you're using ovirt 3.4 make sure you set the cluster policy too On Sat, Feb 8, 2014 at 3:15 PM, Alan Murrell <lists@murrell.ca> wrote:
I followed your notes, installing Squid on my oVirt server (I have an all-in-one installation). I set a port forward on our firewall for port 3128 to my oVirt server.
I logged into the User Portal and tried connecting to the console, but I get "Could not connect to graphic server (null)". Not sure if I have overlooked something?
-Alan
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Just got a chance to get back to this. Looks like I cannot connect using SPICE at all, even from the internal network. I could connect fine (from internal network) before the attempted proxy changes :-( When I try to connect using SPICE, the black console windows pops ups, and just says "Connecting to graphic server", then just stays there. I can connect using VNC, if that helps shed any light. To answer Andrew's questions: Quoting "Andrew Lau" <andrew@andrewklau.com>:
- Can you connect to squid from your browser?
If I go to <http://vm-mgmt01.localdomain:3128> in my browser I get: --- START --- ERROR The requested URL could not be retrieved The following error was encountered while trying to retrieve the URL: / Invalid URL Some aspect of the requested URL is incorrect. Some possible problems are: Missing or incorrect access protocol (should be "http://" or similar) Missing hostname Illegal double-escape in the URL-Path Illegal character in hostname; underscores are not allowed. Your cache administrator is root. --- END ---
- Did you modify the squid.conf to match your setup? (dst addresses, etc).
I have the following for my SPICE config: --- START --- # SPICE proxy http_access deny CONNECT !Safe_ports acl spice_servers dst 10.20.37.0/24 http_access allow spice_servers --- END --- <10.20.37.0/24> is my internal network.
- iptables?
I made the suggested ACCEPT entry, but just to be sure, I completely stopped iptables so the server was wide-open and still unable to connect to SPICE. Still get same error when trying to connect to to the proxy.
- restarted engine?
I did. I also tried the following (restarted engine and tested after each attempt): - engine-config -s SpiceProxyDefault= (i.e., set it back to blank, and also stopped Squid) - engine-config -s SpiceProxyDefault="http://10.20.37.104:3128" (the internal IP of my ovirt-engine/all-in-one server. I also had Squid started for this test) The results were the same: SPICE console just stuck on "Connecting to graphic server" I think I really bollocks'd this one up and may need to do a fresh install and try again.
- If you're using ovirt 3.4 make sure you set the cluster policy too
Using 3.3 from Yum repository. -Alan
Looks like I am talking to myself now, but I will post my latest findings, as I have had some time today to poke at this a bit. It seems that the issues I last posted about may be specific to whn using the Windows Remote-Viewer client, as that is what I was testing with yesterday (and when I was logged in remotely). I can connect from the local network when using the Remote Viewer on my Linux laptop. I will try from remote when I get home, but I still cannot connect from a local Windiws machine. Also, I wanted to confirm what the value for "SpideDefaultProxy" should be, when behine NAT. Should it be: * the value of the external IP/hostname, or * the value of the internal IP/hostname of the server where the proxy is installed (in my case, on the All-In-One setup) The reason I ask is for a couple of reasons: * If I used the value of the external hostname, I was unable to connect from my Linux laptop on the local network (same symptoms as when trying to connect from the Windows PC, as detailed in my previous post). However, if I edited my local "hosts" file to resolve hostname we use externally to the IP of the SPiceProxy server, I was then able to connect to the SPICE session. I believe this is because our firewall does not allow "hairpinning", so it wa denying the "return" connection * If the correct value is indeed the external IP/hostname, then if the firewall denies "hairpinning" connections, will the conenction from outside be blocked due to that as well? I hope the above makes sense. Let me know if you need clarification on the above. In any event, I will update on my test from outside. -Alan
Your value for SpiceDefaultProxy should be your external IP address/hostname otherwise external users will never know where to connect to. This then becomes more of a firewall issue as you're spice proxy is working. But just to confirm, if you open up console through chrome it should download a console.vv file rather than opening up remote-viewer natively, before you run it; open it with a text editor you'll see the proxy settings there. The windows issue is probably just related to non proper drives installed. On Wed, Feb 12, 2014 at 1:07 PM, Alan Murrell <alan@murrell.ca> wrote:
Looks like I am talking to myself now, but I will post my latest findings, as I have had some time today to poke at this a bit.
It seems that the issues I last posted about may be specific to whn using the Windows Remote-Viewer client, as that is what I was testing with yesterday (and when I was logged in remotely). I can connect from the local network when using the Remote Viewer on my Linux laptop. I will try from remote when I get home, but I still cannot connect from a local Windiws machine.
Also, I wanted to confirm what the value for "SpideDefaultProxy" should be, when behine NAT. Should it be:
* the value of the external IP/hostname, or * the value of the internal IP/hostname of the server where the proxy is installed (in my case, on the All-In-One setup)
The reason I ask is for a couple of reasons:
* If I used the value of the external hostname, I was unable to connect from my Linux laptop on the local network (same symptoms as when trying to connect from the Windows PC, as detailed in my previous post). However, if I edited my local "hosts" file to resolve hostname we use externally to the IP of the SPiceProxy server, I was then able to connect to the SPICE session. I believe this is because our firewall does not allow "hairpinning", so it wa denying the "return" connection * If the correct value is indeed the external IP/hostname, then if the firewall denies "hairpinning" connections, will the conenction from outside be blocked due to that as well?
I hope the above makes sense. Let me know if you need clarification on the above. In any event, I will update on my test from outside.
-Alan _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Quoting "Andrew Lau" <andrew@andrewklau.com>:
Your value for SpiceDefaultProxy should be your external IP address/hostname otherwise external users will never know where to connect to.
So the spice proxy would be going out the firewall then looping back in (also known as "hairpinning"), which in my experience is usually a behaviour denied by many firewalls as standard, which is what I believe is happening here.
This then becomes more of a firewall issue as you're spice proxy is
I agree. Would you be willing to share the current IPTables rules on your external firewall so I can confirm this? (sanitised appropriately for actual IPs and/or hostnames, of course) You can contact me off-list if you prefer. This is more for curiousity/confirmation than anything else. I know that when I was on the same LAN as the oVirt box, I had to edit my local hosts file to point the proxy value to the oVirt box itself for the remote-viewer to connect to the Windows desktop. If that is indeed what is happening here, I think a better (and more universal) solution would be to have a VPN connection from the remote end user to the network where the oVirt/RHEV server is (site-to-site if the users are in an office and "road warrior" for remote individuals). Not sure how much of a performance hit that might make, though. Will need to do some testing.
working. But just to confirm, if you open up console through chrome it should download a console.vv file rather than opening up remote-viewer natively, before you run it; open it with a text editor you'll see the proxy settings there.
I took a look and the proxy settings are correct.
The windows issue is probably just related to non proper drives installed.
On the machine I am connecting from or the virtual machine I am connecting to? I downloaded the client from the link here: http://www.spice-space.org/download.html Is there a different SPICE client for Windows that is recommended? -Alan
You just need some proper DST and SRC Nat rules and you should be fine. I use mikrotik so its slightly different but the same concept applies. For windows, I don't know, never really cared much as no one uses windows on our ovirt setup :) But the client tools you linked are for the client accessing the spice session. On Feb 14, 2014 3:20 AM, "Alan Murrell" <alan@murrell.ca> wrote:
Quoting "Andrew Lau" <andrew@andrewklau.com>:
Your value for SpiceDefaultProxy should be your external IP
address/hostname otherwise external users will never know where to connect to.
So the spice proxy would be going out the firewall then looping back in (also known as "hairpinning"), which in my experience is usually a behaviour denied by many firewalls as standard, which is what I believe is happening here.
This then becomes more of a firewall issue as you're spice proxy is
I agree. Would you be willing to share the current IPTables rules on your external firewall so I can confirm this? (sanitised appropriately for actual IPs and/or hostnames, of course) You can contact me off-list if you prefer. This is more for curiousity/confirmation than anything else.
I know that when I was on the same LAN as the oVirt box, I had to edit my local hosts file to point the proxy value to the oVirt box itself for the remote-viewer to connect to the Windows desktop.
If that is indeed what is happening here, I think a better (and more universal) solution would be to have a VPN connection from the remote end user to the network where the oVirt/RHEV server is (site-to-site if the users are in an office and "road warrior" for remote individuals). Not sure how much of a performance hit that might make, though. Will need to do some testing.
working. But just to confirm, if you open up console through chrome it
should download a console.vv file rather than opening up remote-viewer natively, before you run it; open it with a text editor you'll see the proxy settings there.
I took a look and the proxy settings are correct.
The windows issue is probably just related to non proper drives installed.
On the machine I am connecting from or the virtual machine I am connecting to? I downloaded the client from the link here:
http://www.spice-space.org/download.html
Is there a different SPICE client for Windows that is recommended?
-Alan _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
On Feb 14, 2014, at 01:38 , Andrew Lau <andrew@andrewklau.com> wrote:
You just need some proper DST and SRC Nat rules and you should be fine.
I use mikrotik so its slightly different but the same concept applies. For windows, I don't know, never really cared much as no one uses windows on our ovirt setup :)
the recent enough virt-viewer should work on Windows…if you're in fact talking about a client downloaded from http://virt-manager.org/download/ it should work… for NAT vs non-NAT access ….for exactly that reason there is the "Enable SPICE Proxy" checkbox in Console Options dialog for each user, so you can check it when connecting from outside and uncheck from local net… Thanks, michal
But the client tools you linked are for the client accessing the spice session.
On Feb 14, 2014 3:20 AM, "Alan Murrell" <alan@murrell.ca> wrote: Quoting "Andrew Lau" <andrew@andrewklau.com>:
Your value for SpiceDefaultProxy should be your external IP address/hostname otherwise external users will never know where to connect to.
So the spice proxy would be going out the firewall then looping back in (also known as "hairpinning"), which in my experience is usually a behaviour denied by many firewalls as standard, which is what I believe is happening here.
This then becomes more of a firewall issue as you're spice proxy is
I agree. Would you be willing to share the current IPTables rules on your external firewall so I can confirm this? (sanitised appropriately for actual IPs and/or hostnames, of course) You can contact me off-list if you prefer. This is more for curiousity/confirmation than anything else.
I know that when I was on the same LAN as the oVirt box, I had to edit my local hosts file to point the proxy value to the oVirt box itself for the remote-viewer to connect to the Windows desktop.
If that is indeed what is happening here, I think a better (and more universal) solution would be to have a VPN connection from the remote end user to the network where the oVirt/RHEV server is (site-to-site if the users are in an office and "road warrior" for remote individuals). Not sure how much of a performance hit that might make, though. Will need to do some testing.
working. But just to confirm, if you open up console through chrome it should download a console.vv file rather than opening up remote-viewer natively, before you run it; open it with a text editor you'll see the proxy settings there.
I took a look and the proxy settings are correct.
The windows issue is probably just related to non proper drives installed.
On the machine I am connecting from or the virtual machine I am connecting to? I downloaded the client from the link here:
http://www.spice-space.org/download.html
Is there a different SPICE client for Windows that is recommended?
-Alan _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users _______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (4)
-
Alan Murrell -
Alan Murrell -
Andrew Lau -
Michal Skrivanek