Everything except the password is not supported. Strange thing is when I
try the change the line to:
vm.update_display(:password => password)
I still get the same error. I suspect Fog to send something through the
line anyway which differs from my own listen address which is 0.0.0.0
(this host was not created via Foreman).
I wonder why do we set the listen address to "0" value. And do you have
any clue why it does not work when I only send the password?
> Hello,
>
> when I click on the CONSOLE button I always get the following error:
>
> cannot change listen address setting on vnc graphics
>
> I do not understand why do we set listen address to zero here:
>
> lib/foreman/model/libvirt.rb#console:
> vm.update_display(:password => password, :listen => '0')
>
> It looks like QEMU does not support changing of listen addresses for the
> running instance at all:
>
> http://code.metager.de/source/xref/libvirt/src/qemu/qemu_hotplug.c#1861
>
> Everything except the password is not supported. Strange thing is when I
> try the change the line to:
>
> vm.update_display(:password => password)
>
> I still get the same error. I suspect Fog to send something through the
> line anyway which differs from my own listen address which is 0.0.0.0
> (this host was not created via Foreman).
>
> I wonder why do we set the listen address to "0" value. And do you have
> any clue why it does not work when I only send the password?
if you are updating an existing system (not created via foreman) make
sure that both listen and addresss sections are set to 0.
the main reason is that nearly always, foreman instance wont be the
hypervisor, which means the websocket proxy would need to connect
remotely into the system.
Ohad
···
On Fri, Apr 5, 2013 at 6:49 PM, Lukas Zapletal wrote:
I don't see that behaviour actually - my libvirt hosts could be viewed in
virt-manager (assuming I supply the password from the XML file). I did
occaisonally get that error, but it seemed to be hypervisor related, and
restarting virt-manager fixed it.
HTH,
Greg
···
On 19 May 2013 11:27, Ryan Davies wrote:
But why set to “0” ? Why not “0.0.0.0” ?
Setting to 0 breaks other tools such as virt-manager from connecting:
“Error: viewer connection to hypervisor host got refused or disconnected”
Regardless, setting the listen address to 0 is breaking libvirt's API
standard, http://libvirt.org/formatdomain.html#elementsGraphics (as far as
i'm aware that is)
addressif type='address', the address attribute will contain either an IP
address or hostname (which will be resolved to an IP address via a DNS
query) to listen on. In the "live" XML of a running domain, this attribute
will be set to the IP address used for listening, even if type='network'.
On a side note, if i change
lib/foreman/model/libvirt.rb#console:
vm.update_display(:password => password, :listen => '0')
The websocket still works (and starts working for existing systems), and
virt-manager starts working again (For newly defined machines)
Regards,
Ryan
···
On Monday, May 20, 2013 8:21:35 AM UTC+12, Greg Sutcliffe wrote:
>
> On 19 May 2013 11:27, Ryan Davies <ry...@ryandavies.co.nz >wrote:
>
>> But why set to "0" ? Why not "0.0.0.0" ?
>>
>> Setting to 0 breaks other tools such as virt-manager from connecting:
>> "Error: viewer connection to hypervisor host got refused or disconnected"
>>
>> Ryan
>>
>
> I don't see that behaviour actually - my libvirt hosts could be viewed in
> virt-manager (assuming I supply the password from the XML file). I did
> occaisonally get that error, but it seemed to be hypervisor related, and
> restarting virt-manager fixed it.
>
> HTH,
> Greg
>
> I get this constantly.
>
> Regardless, setting the listen address to 0 is breaking libvirt's API
> standard, http://libvirt.org/formatdomain.html#elementsGraphics (as far
> as i'm aware that is)
> addressif type='address', the address attribute will contain either an IP
> address or hostname (which will be resolved to an IP address via a DNS
> query) to listen on. In the "live" XML of a running domain, this attribute
> will be set to the IP address used for listening, even if type='network'.
>
> On a side note, if i change
> lib/foreman/model/libvirt.rb#**console:
> vm.update_display(:password => password, :listen => '0')
>
> to
>
> lib/foreman/model/libvirt.rb#**console:
> vm.update_display(:password => password, :listen => '0.0.0.0')
>
> The websocket still works (and starts working for existing systems), and
> virt-manager starts working again (For newly defined machines)
>
I can't remember the real reason for 0 vs 0.0.0.0, but it was shamlessly
copied from vdsm code, assuming they had a good reason, if you confirm that
0.0.0.0 works as well i dont mind accepting this as a bug fix for 1.2
Ohad
···
On Mon, May 20, 2013 at 2:14 AM, Ryan Davies wrote:
Regards,
Ryan
On Monday, May 20, 2013 8:21:35 AM UTC+12, Greg Sutcliffe wrote:
Setting to 0 breaks other tools such as virt-manager from connecting:
“Error: viewer connection to hypervisor host got refused or disconnected”
Ryan
I don’t see that behaviour actually - my libvirt hosts could be viewed in
virt-manager (assuming I supply the password from the XML file). I did
occaisonally get that error, but it seemed to be hypervisor related, and
restarting virt-manager fixed it.
from the libvirt sources (qemu_hotplug.c function
qemuDomainChangeGraphics) it looks like QEMU does not support changing
listen address on the fly for both VNC and Spice drivers. If you send
the very same address there, the update_display command will not fail
tho.
In your case, you obviously created the display with value of 0.0.0.0
instead of 0, so it is working for you. On the other hand, when I was
testing it I was creating a libvirt guest with listen address set to 0
(zero), so your patch actually breaks it.
I am afraid I don't know which value is the "right" one. It looks like
everybody has different parameters for non-managed libvirt guests.
The question is - do we need to set the listen address? From the libvirt
sources it looks like it cannot be changed at all. Maybe we can get rid
of this parameter (I think I already raised this topic one month ago).
···
On Sun, May 19, 2013 at 04:14:41PM -0700, Ryan Davies wrote:
> On a side note, if i change
> lib/foreman/model/libvirt.rb#console:
> vm.update_display(:password => password, :listen => '0')
>
> to
>
> lib/foreman/model/libvirt.rb#console:
> vm.update_display(:password => password, :listen => '0.0.0.0')
>
> The websocket still works (and starts working for existing systems), and
> virt-manager starts working again (For newly defined machines)
No, My machines were created with listen address 0 as default by foreman,
it was only AFTER changing them to 0.0.0.0 that the display both worked in
foreman and virt-manager.
My patch will break existing hosts (Where the listen address is incorrectly
set to 0) as yes the listen address cannot be changed on the fly but only
while the guest is running.
···
On Wed, May 22, 2013 at 4:36 AM, Lukas Zapletal wrote:
On Sun, May 19, 2013 at 04:14:41PM -0700, Ryan Davies wrote:
On a side note, if i change
lib/foreman/model/libvirt.rb#console:
vm.update_display(:password => password, :listen => ‘0’)
The websocket still works (and starts working for existing systems), and
virt-manager starts working again (For newly defined machines)
Hey,
from the libvirt sources (qemu_hotplug.c function
qemuDomainChangeGraphics) it looks like QEMU does not support changing
listen address on the fly for both VNC and Spice drivers. If you send
the very same address there, the update_display command will not fail
tho.
In your case, you obviously created the display with value of 0.0.0.0
instead of 0, so it is working for you. On the other hand, when I was
testing it I was creating a libvirt guest with listen address set to 0
(zero), so your patch actually breaks it.
I am afraid I don’t know which value is the “right” one. It looks like
everybody has different parameters for non-managed libvirt guests.
The question is - do we need to set the listen address? From the libvirt
sources it looks like it cannot be changed at all. Maybe we can get rid
of this parameter (I think I already raised this topic one month ago).
> > The question is - do we need to set the listen address? From the libvirt
> > sources it looks like it cannot be changed at all. Maybe we can get rid
> > of this parameter (I think I already raised this topic one month ago).
Ohad, why do we have the zero there in the first place? For running
guests we cannot change it at all while it could work without the listen
parameter assuming the listen address is set correctly.
I think we should remove it completely. Even 0.0.0.0 is not great (I can
have a specific interface address there).
> > > The question is - do we need to set the listen address? From the
> libvirt
> > > sources it looks like it cannot be changed at all. Maybe we can get rid
> > > of this parameter (I think I already raised this topic one month ago).
>
> Ohad, why do we have the zero there in the first place?
I shamelessly copied it from vdsm assuming they had a good reason.
> For running
> guests we cannot change it at all while it could work without the listen
> parameter assuming the listen address is set correctly.
>
right, but default is to listen only on loopback devices.
>
> I think we should remove it completely. Even 0.0.0.0 is not great (I can
> have a specific interface address there).
>
what do you suggest? just fail on connection timeout instead?
Ohad
···
On Wed, May 22, 2013 at 10:01 PM, Lukas Zapletal wrote:
> > what do you suggest? just fail on connection timeout instead?
> >
>
> We could read that attribute and check if it is set correctly instead of
> trying to set it.
>
sure, easy enough, but then you still need to figure out if you can reach
it or not (if its not 0.0.0.0)
Ohad
···
On Wed, May 22, 2013 at 10:14 PM, Lukas Zapletal wrote:
> On Wed, May 22, 2013 at 10:04:22PM +0300, Ohad Levy wrote:
I dont understand why - can't we just let browser to try and timeout?
I mean isn't this an extra check?
LZ
···
On Wed, May 22, 2013 at 10:16:05PM +0300, Ohad Levy wrote:
> On Wed, May 22, 2013 at 10:14 PM, Lukas Zapletal wrote:
>
> > On Wed, May 22, 2013 at 10:04:22PM +0300, Ohad Levy wrote:
> > > what do you suggest? just fail on connection timeout instead?
> > >
> >
> > We could read that attribute and check if it is set correctly instead of
> > trying to set it.
>
> sure, easy enough, but then you still need to figure out if you can reach
> it or not (if its not 0.0.0.0)
>
