Bug 985813 - [Admin Portal] Host's Display address is not immediately applied - entity (VM) data seems to be cached
[Admin Portal] Host's Display address is not immediately applied - entity (VM...
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-webadmin-portal (Show other bugs)
Unspecified Unspecified
unspecified Severity medium
: ---
: 3.3.0
Assigned To: Tomas Jelinek
Jiri Belka
: Triaged
Depends On:
  Show dependency treegraph
Reported: 2013-07-18 06:03 EDT by Jiri Belka
Modified: 2015-09-22 09 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-08-09 09:38:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jiri Belka 2013-07-18 06:03:21 EDT
Description of problem:

BZ788977 introduced possibility to override SetHostIP (display address) which is used by console clients while connectiong to spice/vnc ports of qemu-kvm process.

Problem is that changed value in Hosts -> $host (edit) -> Console -> Display address - is not "immediately" applied. But the problem is not in the value itself, but in web application, probably more specifically in Virtual Machines maintab, and/or how it handles/caches entities data.

That means, if you have default setup of your engine, and you open a SPICE console of a VM, the VM entity line in Virtual Machines maintab is selected. Then when you change 'Display address' with changing maintab to Hosts and changing settings of a specific hosts, then switching back to Virtual Machines maintab, right-click on the previously selected VM and select Console, this would not update the value defined in hosts properties and thus it would use old value for SetHostIP! After this action, the VM line is selected/highlighted, open the console with console icon in main action bar. This again uses old value. Selecting different VM and then selecting back the previous VM makes the entity data updated and next console opening used new SetHostIP.


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

How reproducible:
100% (but difficult)

Steps to Reproduce:
1. default engine environment
2. select a VM (let's call it FOO) and check on client spice log (tail -f .spicec/spice-xpi.log | grep SetHostIP)
3. switch to Hosts maintab, select Host and change Console settings (override display address is selected and put some value in display address field)
4. switch back to Virtual Machines maintab, right-click on FOO VM and select console
5. select a VM (let's call it FOO) and check on client spice log (tail -f .spicec/spice-xpi.log | grep SetHostIP)
6. open FOO VM console with console icon
7. select to other vm, select to another vm, select FOO VM again
8. open console

Actual results:
2 - shows IP address (default mode)
5 - shows IP address (but it should show changed value)
6 - shows IP address (but it should show changed value)
8 - shows changed value

Expected results:
change value should be applied immediatelly

Additional info:

$ egrep "^log4j.*DEBUG" /etc/spice/logger.ini 
log4j.rootCategory=DEBUG, R
$ tail -f ~/.spicec/spice-xpi.log | grep SetHostIP
Comment 1 Tomas Jelinek 2013-08-09 01:59:51 EDT
The problem is that the display address is a host property so it's update is the update of the host. 

The display address of the VM is a VM's dynamic property managed in the VDSM polling thread. 

So the display address is not really cached - it is updated after the VM's dynamic data get updated. So basically the steps to reproduce could be simplified to: 
1: go to the host tab and change the display address
2: quickly go back to the VMs tab and open the console (if you where quick enough the display address will be still the old)
3: wait couple of seconds and try again (the new address will be used)

I'm not sure if this is a bug or a correct behavior according to our architecture. I see the following options how to proceed:

1: accept the fact that the display address is managed by the host polling thread. Since the host console address is not expected to be changed too often, it should be ok to wait few seconds until the VMs get updated.

2: after updating the host, update all the VMs running on it. It can bring some issues by interfering with the polling thread but can be certainly solved.

@Michal: what do you think?
Comment 2 Michal Skrivanek 2013-08-09 09:38:09 EDT
this would rarely happen in real life and it is updated correctly in the next refresh period, the same way as all the other things (except VM state changes). 

We are investigating how to address that globally, so eventually the delay would be shorter, but it's far from getting in. For now I suggest to CLOSE as no specific action/change is needed

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