Bug 1271791
| Summary: | vdsm reporting vm 'displayIp=0' | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Amador Pahim <asegundo> |
| Component: | vdsm | Assignee: | Dan Kenigsberg <danken> |
| Status: | CLOSED WORKSFORME | QA Contact: | Aharon Canan <acanan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3.5.3 | CC: | bazulay, ecohen, gklein, lsurette, rbalakri, Rhev-m-bugs, ycui, yeylon |
| Target Milestone: | ovirt-3.6.0-rc3 | ||
| Target Release: | 3.6.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | virt | ||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-10-22 11:23:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
This is an issue because external monitoring tools using the API to retrieve the console address are expecting a stable behavior. 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.
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. |
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.