Bug 1271791 - vdsm reporting vm 'displayIp=0'
vdsm reporting vm 'displayIp=0'
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm (Show other bugs)
All Linux
medium Severity medium
: ovirt-3.6.0-rc3
: 3.6.0
Assigned To: Dan Kenigsberg
Aharon Canan
Depends On:
  Show dependency treegraph
Reported: 2015-10-14 14:09 EDT by Amador Pahim
Modified: 2016-02-10 14:23 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2015-10-22 07:23:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Amador Pahim 2015-10-14 14:09:54 EDT
Accessing VMs console, some VMs have the IP address for the console access, other VMs have the hostname.


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,

The result is:

NAME: vm01; DISPLAY: host01.example.com
NAME: vm02; DISPLAY:   <-- 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 07:20:20 EDT
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 09:15:26 EDT
Checking on 3.5.3 source code, we have a situation where we use the hostname instead of the ip address:


 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:


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 07:23:07 EDT
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.