Hide Forgot
Description of problem: When creating a new host ("hosta") in a RHEV compute resource using a specific domain ("example.com") the RHEV VM is named "hosta-example-com" rather than "hosta.example.com". Version-Release number of selected component (if applicable): 6.1.7 How reproducible: Always Steps to Reproduce: 1. Create a new host ("hosta") on a RHEV compute resource using an existing template 2. 3. Actual results: RHEV VM is named "hosta-example-com" Expected results: RHEV VM is named "hosta.example.com" Additional info:
See related foreman issue http://projects.theforeman.org/issues/10278 . RHEV accepts dots for VM names since RHEV 3.1, see https://access.redhat.com/solutions/138643 . Consequently the following patch could be reverted: https://github.com/theforeman/foreman/blob/1.8.0-RC3/app/models/compute_resources/foreman/model/ovirt.rb#L139-L140
In file /usr/share/foreman/app/models/compute_resources/foreman/model/ovirt.rb : 139 def create_vm(args = {}) * 140 #ovirt doesn't accept '.' in vm name. * 141 args[:name] = args[:name].parameterize 142 if (image_id = args[:image_id]) Customer confirms that removing lines 140 and 141 results in VM names being created with dots (hosta.example.com).
Increasing severity since this affects all RHEV VMs created from Satellite that include dots in the name.
Connecting redmine issue http://projects.theforeman.org/issues/10278 from this bug
The patch against foreman opened to fix the issue https://github.com/theforeman/foreman/pull/3415
Moving to POST since upstream bug http://projects.theforeman.org/issues/10278 has been closed ------------- Dominic Cleal https://github.com/theforeman/foreman/blob/1.8.0-RC3/app/models/compute_resources/foreman/model/ovirt.rb#L139-L140 is responsible, for reference. ------------- Ivan Necas Applied in changeset commit:cf826485d252e8f1d7fee7209c561751915ea338.
Verified with Sat6.3 snap 18. Creating RHEV guests from Create Host dialog results in guests with dots in their name (rather than replacing dots with hyphens). The systems are indeed created also in Satellite and they can be power managed. This seems to work, just note this actually changes behavior observable by customers and can, for example, break some of ther scripts. This is, however, expected as per comment 7.
qe_test_coverage PR: https://github.com/SatelliteQE/robottelo/pull/5692
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0336