[ops] Openstack Victoria SPICE configuration not working
stephenfin at redhat.com
Mon Aug 9 15:48:03 UTC 2021
On Mon, 2021-08-09 at 10:36 -0500, number9 wrote:
> On 2021-08-09 05:59, Stephen Finucane wrote:
> > On Thu, 2021-08-05 at 12:25 -0500, number9 wrote:
> > > I have posted this on stackexchange, but am also asking here:
> > >
> > > Running openstack on Ubuntu 20.04 with a controller node and four
> > > compute nodes. I am reading the instructions on configuring SPICE
> > > here.
> > > I will admit, I found out about which packages to install from other
> > > sites, as the instructions at the link do not actually list any
> > > software
> > > that needs to be installed.
> > >
> > > On the compute nodes and controller, I installed nova-spiceproxy
> > > On the controller I installed nova-spiceproxy and spice-html5
> > Not an answer, but as an aside SPICE support is poorly maintained in
> > nova and
> > its usage not generally advised. It may be removed in a future release.
> > I would
> > suggest relying on noVNC instead. With that said...
> Hrm, I might try to go back to noVNC. I could never get that working
> > >
> > > I followed the instructions in the link on configuring
> > > /etc/nova/nova.conf on the controller and all compute nodes.
> > >
> > There's a typo here, but it shouldn't matter - that config option has
> > been
> > replaced by the '[vnc] enabled' option below. The doc clearly needs an
> > update.
> > As another aside, because virtually everyone seems to use an installer,
> > the
> > actual install guides get very TLC and are subsequently prone to bitrot
> > :(
> > However, the remote console doc at  was updated in recent releases
> > and should
> > be relatively accurate.
> > 
> > https://docs.openstack.org/nova/latest/admin/remote-console-access.html
> I have been referencing the above doc. I am just noting that I was
> in redundancies as I never know what is really working in the configs
> there are differences from say one version to the next.
> > > # yes, I know it is redundant, I am following the docs...
> > >
> > > [vnc]
> > > enabled = false
> > >
> > > [spice]
> > > enabled = true
> > > agent_enabled = true
> > > html5proxy_base_url = http://10.131.39.40:6082/spice_auto.html
> > > # the above IP is the IP of the controller.
> > > server_listen = 0.0.0.0
> > > server_proxyclient_address = 10.131.29.42
> > So I assume '10.131.39.40' is address of the controller and
> > '10.131.29.42' is
> > the address of the compute node, yes? Is the former publicly accessible
> > from the
> > same place you're browsing the web UX? I would assume not, given it's a
> > private
> > network IP. If not, this needs to be updated. This is the value
> > returned from
> > the API which is in turn used by Horizon iirc.
> YES, the private internal IIP address scheme is what people hit horizon
> on. The clients are am on a private internal network.
Another thing to try is to connect the server directly using a local SPICE or
VNC client. The IP address will be the IP of the compute host, while the port
can be seen in the XML for each individual instance. This isn't a long-term
solution but it's another way to rule out potentially faulty or misconfigured
> > I suspect the issue is with the address used for '[spice]
> > html5proxy_base_url'.
> > I would suggest using the 'openstack console url show' command to get a
> > URL to
> > access the console without needing to invoke Horizon. If you're able to
> > access
> > this URL then the issue is instead somewhere in Horizon. If not, it's
> > definitely
> > nova. You can also enable debug-level logging for the
> > nova-spicehtml5proxy and
> > nova-novncproxy services to ensure you're actually seeing a connection
> > from your
> > browser.
> I will check openstack console url show
> It says I need a <server>, but no matter what I put in, I get "no server
> name or ID of that exists".
> Huh, perhaps I am loosing my mind? I can login to horizon and spin up
> VMs, but this is blank:
> openstack server list
> As I was trying different server names on openstack console url show.
This sounds like you are using a different tenant/project and possibly different
user for the CLI vs. the web UI. If you're using a stackrc file, check the value
of the 'OS_PROJECT_ID' and 'OS_PROJECT_NAME' environment variables against
what's showing in your web UI (top right corner, iirc). If you're using a
'clouds.yaml' file, check the value of 'clouds.$cloud.auth.project_id' and
'clouds.$cloud.auth.project_name' against same.
More information about the openstack-discuss