Bug 1271791 - vdsm reporting vm 'displayIp=0'
Summary: vdsm reporting vm 'displayIp=0'
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.5.3
Hardware: All
OS: Linux
medium
medium
Target Milestone: ovirt-3.6.0-rc3
: 3.6.0
Assignee: Dan Kenigsberg
QA Contact: Aharon Canan
URL:
Whiteboard: virt
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-10-14 18:09 UTC by Amador Pahim
Modified: 2019-08-15 05:41 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-10-22 11:23:07 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Amador Pahim 2015-10-14 18:09:54 UTC
Accessing VMs console, some VMs have the IP address for the console access, other VMs have the hostname.

rhevm-3.5.3.1-1.4.el6ev.noarch

Using the python sdk script with the lines bellow:

...
for vm in api.vms.list():
    if vm.status.state == 'up':
        print("NAME: %s; DISPLAY: %s" % (vm.name,
               vm.get_display().get_address()))
...

The result is:

...
NAME: vm01; DISPLAY: host01.example.com
NAME: vm02; DISPLAY: 10.0.0.101   <-- Host01 IP address
...

This issue was observed only in the original environment. I'm not able to reproduce. In my env., all VMs have the Host IP address for display, regardless host being added to RHEV using hostname or IP address. The only way I could have the hostname for display address was setting the Host 'Override display address', but that's not the case for the original env.

Expected result:

Find the root cause associated to the inconsistent behavior and estate what's the expected behavior, if using IP or hostname.

Comment 2 Amador Pahim 2015-10-15 11:20:20 UTC
This is an issue because external monitoring tools using the API to retrieve the console address are expecting a stable behavior.

Comment 3 Amador Pahim 2015-10-15 13:15:26 UTC
Checking on 3.5.3 source code, we have a situation where we use the hostname instead of the ip address:

(backend/manager/modules/vdsbroker/src/main/java/org/ovirt/engine/core/vdsbroker/vdsbroker/ExtendedVmDynamic.java)

 16     public void setDisplayIp(String value) {
 17         if (host.getConsoleAddress() != null) {
 18             super.setDisplayIp(host.getConsoleAddress());
 19         } else if (value.startsWith("0")) {
 20             super.setDisplayIp(host.getHostName());  <----- Using hostname
 21         } else {
 22             super.setDisplayIp(value);
 23         }
 24     }

According to the snip above, the hostname will be used when vdsm returns displayIp=0.

Checking the logs to see if that's the case:

(engine.log)

2015-10-09 16:11:22,646 INFO [org.ovirt.engine.core.vdsbroker.VdsUpdateRunTimeInfo] (DefaultQuartzScheduler_Worker-87) [568d2498] Received a vnc Device without an address when processing VM bcb5c980-e8e9-4b6d-b0f3-add8544478d2 devices, skipping device: {port=5909, specParams={spiceSecureChannels=smain,sinputs, keyMap=en-us, displayIp=0}, device=vnc, type=graphics}

vdsm is indeed returning displayIp as '0'.

Checking vdsm to see why this happens:

...
5718         self.conf['displayIp'] = _getNetworkIp(
5719             self.conf.get('displayNetwork'))
...
...
5739 def _getNetworkIp(network):
5740     try:
5741         nets = netinfo.networks()
5742         device = nets[network].get('iface', network)
5743         ip = netinfo.getaddr(device)
5744     except (libvirt.libvirtError, KeyError, IndexError):
5745         ip = config.get('addresses', 'guests_gateway_ip')
5746         if ip == '':
5747             ip = '0'               <-------- displayIp set to 0
5748         logging.info('network %s: using %s', network, ip)
5749     return ip
...

An error in getNetworkIp() will set the displayIp to 0. Changing component to vdsm and checking why is getNetworkIp() failing.

Comment 4 Amador Pahim 2015-10-22 11:23:07 UTC
The issue is not reproducible and it's not happening anymore on original env. The VMs started more than 100 days ago, they still have the display_ip with hostname and the available vdsm logs are not that old. VMs started from a certain point onwards are getting the IP address as expected, so I will close this bz for now. Feel free to reopen it case you face this issue again.


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