Bug 1130159 - No clear error when viewing VM console when hypervisor hostname doesn't resolve
Summary: No clear error when viewing VM console when hypervisor hostname doesn't resolve
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Satellite 6
Classification: Red Hat
Component: Compute Resources
Version: 6.0.3
Hardware: Unspecified
OS: Unspecified
unspecified
medium vote
Target Milestone: Unspecified
Assignee: Dominic Cleal
QA Contact: Katello QA List
URL: http://projects.theforeman.org/issues...
Whiteboard:
Depends On:
Blocks: 1139277
TreeView+ depends on / blocked
 
Reported: 2014-08-14 13:03 UTC by David Juran
Modified: 2017-01-05 19:14 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-01-05 19:14:37 UTC


Attachments (Terms of Use)
domain XML (2.62 KB, text/xml)
2014-08-18 13:30 UTC, David Juran
no flags Details


Links
System ID Priority Status Summary Last Updated
Foreman Issue Tracker 7117 None None None 2016-04-22 16:01:38 UTC

Description David Juran 2014-08-14 13:03:24 UTC
Description of problem:
after creating a host configured with a spice console on a libvirt computer provider, if I try to view the console from the satellite 6, I only get a red banner with the text " Error: Unexpected protocol mismatch"

Version-Release number of selected component (if applicable):
satellite 6.0.3

How reproducible:
Every time

Steps to Reproduce:
1. try to view the console of a host on libvirt configured with spice

Comment 1 RHEL Product and Program Management 2014-08-14 13:23:02 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 3 Bryan Kearney 2014-08-15 20:22:19 UTC
Created redmine issue http://projects.theforeman.org/issues/7117 from this bug

Comment 4 Dominic Cleal 2014-08-18 07:56:10 UTC
Edit the libvirt domain XML, if you have something similar to this:

    <graphics type='spice' autoport='yes'/>

Then change it to:

    <graphics type='spice' autoport='yes' listen='0.0.0.0'/>

Otherwise Foreman won't be able to connect to the console on your libvirt hypervisor.  The default is to listen to 127.0.0.1 only.

Comment 5 David Juran 2014-08-18 13:29:06 UTC
That is how my XML looks, the machine was created from the Sat6 compute provider.
Domain XML attached

Comment 6 David Juran 2014-08-18 13:30:28 UTC
Created attachment 927896 [details]
domain XML

Comment 7 Dominic Cleal 2014-08-18 13:41:07 UTC
Thanks, looks OK.  Do you have any firewalls on the Sat6 server, or between your browser and it?  Is SELinux enforcing?

Check that when you view the console page, "ps auxww | grep [w]ebsockify" shows up a process, please paste the output.  Check the hostname in the last argument of the command line resolves (this is supplied by libvirt and may indicate a misconfiguration if incorrect).

Comment 8 David Juran 2014-08-18 14:44:30 UTC
No firewall on satellite host and AFAIK, no firewall between my browser and the satellite.
SELinux is Permissive and no AVC:s at the time I try to connect.


ps auxww | grep [w]ebsockify
foreman   5911  0.5  0.1 156176 12104 ?        S    16:35   0:00 /usr/bin/python /usr/share/foreman/extras/noVNC/websockify.py --daemon --idle-timeout=120 --timeout=120 5910 localhost.localdomain:5901

Also, tcpdump on the satelite show there is traffic comming from my laptop to port 5010.

Comment 9 Dominic Cleal 2014-08-18 16:05:32 UTC
Is the libvirt compute resource on the same system that runs Satellite 6, or is it different?

If it's different, then it has an identity issue as the "localhost.localdomain" is what libvirt's giving as the hypervisor FQDN.  I've seen this a lot before, but I don't know precisely which config drives it, so would double check the usual "hostname -f" resolution etc.

Comment 10 David Juran 2014-08-19 11:49:38 UTC
Uhm, yes, the compute provider (libvirt host)is different from the satellite. And yes, it did have hostname set to localhost )-:  And fixing that solved the issue.

So would it be possible to somehow make the error message a bit more verbose? If not, feel free to close the bug. And thanks for the help (-:

Comment 12 Bryan Kearney 2015-08-25 18:00:08 UTC
Upstream bug component is Compute Resources

Comment 13 Bryan Kearney 2017-01-05 19:14:37 UTC
This is an older bug which I do not envision being fixed in the near term. I am closing this out. If you belive doing so is an issue, please feel free to re-open and provide additional business information. Thank you.


Note You need to log in before you can comment on or make changes to this bug.