mirror of
https://github.com/retspen/webvirtmgr.git
synced 2026-04-25 23:55:57 +03:00
[GH-ISSUE #416] noVNC not having host or port set for connections #315
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @invisiblethreat on GitHub (Sep 3, 2014).
Original GitHub issue: https://github.com/retspen/webvirtmgr/issues/416
Trying to open a noVNC session has some currently is not working. I've isolated it to
hostandportnot getting set and trying to open a connection toNone:NoneHardcoding
hostandport:leads to successful connections.
I'm running 4.8.8.
@goshlanguage commented on GitHub (Sep 3, 2014):
I'm experiencing the same thing
@goshlanguage commented on GitHub (Sep 3, 2014):
You can temporarily connect to 1 console at a time using websockify to forward ports,
example:
$ websockify 6800 127.0.0.1:5900
The vms all operate on different ports (5900-59x where x = the number of instances you have running). I don't know how to find which port which instance is on however. Hope this helps in the interim.
@retspen commented on GitHub (Sep 4, 2014):
Hover mouse cursor on Console button and you can show vm's port.
@invisiblethreat commented on GitHub (Sep 4, 2014):
Hovering does indeed give the port:
Will use this and websockify in the interim.
@goshlanguage commented on GitHub (Sep 4, 2014):
So is everyone experiencing this issue since the last commit?
@retspen commented on GitHub (Sep 4, 2014):
You can check manually from server:
$ telnet ip_server_where_vm's_run 5901
Have you got connected?
@goshlanguage commented on GitHub (Sep 4, 2014):
They are all listening fine, the issue is that the functionality is broken from the web ui.
If I click on console, it doesn't work unless I am running websockify and manually proxying the port.
This is far more difficult and involved than just clicking consoles from instances. Is this something that is being worked on, or did it just break due to upgrading?
@invisiblethreat commented on GitHub (Sep 4, 2014):
VNC is working fine from the point of view of KVM:
I can connect when manually using
websockify.Some light debugging is showing a problem returning from
Instance.objects.getSomething is silently going wrong inside of the
Instance.objects.getcall from what I can tell.@goshlanguage commented on GitHub (Sep 4, 2014):
I am getting the same thing ^^
@retspen commented on GitHub (Sep 4, 2014):
Change line #52 to
print Instance.objects.all()and show output@invisiblethreat commented on GitHub (Sep 4, 2014):
Results in:
Also checked that things could import as expected:
@invisiblethreat commented on GitHub (Sep 4, 2014):
If I try to re-raise the exception, things get unhappy, and I never get to the "connecting" log message:
@retspen commented on GitHub (Sep 4, 2014):
Change this:
to
and chekck
@daniviga commented on GitHub (Sep 4, 2014):
I'm unable to reproduce this bug on Fedora 20 with up-to-date webvirtmgr and libvirt.
@invisiblethreat commented on GitHub (Sep 4, 2014):
Removing the
tryexceptgives the same behavior as re-raising:@retspen commented on GitHub (Sep 4, 2014):
After line #49
print instance@invisiblethreat commented on GitHub (Sep 4, 2014):
No output. I also tried
print type(instance)which had no output, seems to be not returning, rather than empty.@retspen commented on GitHub (Sep 4, 2014):
Show your data in table instance_instanrce ($ sqlite3 webvirtmgr.sqlite3).
@invisiblethreat commented on GitHub (Sep 4, 2014):
@retspen commented on GitHub (Sep 4, 2014):
And last check, after #48
print uuid, hostand next lineprint Instance.objects.all()@invisiblethreat commented on GitHub (Sep 4, 2014):
@retspen commented on GitHub (Sep 4, 2014):
And
print dir(Instance), Instance.object.all()without try and except block.@invisiblethreat commented on GitHub (Sep 4, 2014):
@retspen commented on GitHub (Sep 4, 2014):
Sorry...
Instance.objects.all().@invisiblethreat commented on GitHub (Sep 4, 2014):
I know that I can't concatenate the
Instanceto the string, but it's a non-issue since we don't seem to get to the call. :(@invisiblethreat commented on GitHub (Sep 4, 2014):
You probably wanted the following:
@retspen commented on GitHub (Sep 5, 2014):
You have got problem with Django models. Can you check this manually?
And show permission webvirtmgr.sqlite3
@invisiblethreat commented on GitHub (Sep 5, 2014):
Progress! (sort of)
I did all the things you asked, and the objects were there. I decided to dump all of the attributes for the object with:
which returned all the expected values. Furthermore, I opened
conn = wvmInstance(instance.compute.hostname,...from the CLI and dumped all attributes as well.I even jacked up permissions to 777 on
webvirtmgr.sqlite3just in in case. It changed nothing when the script was run.I decided to dig deeper:
So
/usr/local/lib/python2.7/dist-packages/webvirtmgr-4.8.7-py2.7.egg/webvirtmgr/../webvirtmgr.sqlite3is being opened, and it's 100% empty. :(So I symlinked it to
/var/www/webvirtmgr/webvirtmgr.sqlite3and then restarted the noVNC service withsupervisorctlwhich revealed an exception condition that appears to be somewhat related to https://github.com/retspen/webvirtmgr/issues/413@retspen commented on GitHub (Sep 5, 2014):
Do you have last version?
@invisiblethreat commented on GitHub (Sep 5, 2014):
Yes. I just re-cloned and deployed again to confirm the behavior.
@retspen commented on GitHub (Sep 5, 2014):
I think your webvirtmgr-novnc import all files from python site-package. Show your
os.path@invisiblethreat commented on GitHub (Sep 5, 2014):
os.path wasn't using site-package, but I dove in deeper when I saw
libvirtdmentioned in #413.I don't think that the install docs should say anything but Debian Testing is supported for 4.8.8+. Debian 7 worked fine until the upgrade, but after that, no dice. Doing a
dist-upgradetotestingsolved these issues.Unfortunately, the
dist-upgradedoes break thenginxconfiguration, which was harder to fix than I hoped, due to the introduction ofsystemd.I'm truly sorry for the time that it has taken to get to this point. :(
I'll re-write the docs for Debian as penance!
@Aidenir commented on GitHub (Dec 21, 2014):
Why was this issue closed? Did you find the solution? Because I'm seeing the exact same issue on Arch and I have not been able to resolve it, neither do I see a fix in this issue.