RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 822930 - DNS info is removed after register to rhevm
Summary: DNS info is removed after register to rhevm
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: ovirt-node
Version: 6.3
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Fabian Deutsch
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks: 824621
TreeView+ depends on / blocked
 
Reported: 2012-05-18 14:25 UTC by shine
Modified: 2016-04-26 14:56 UTC (History)
14 users (show)

Fixed In Version: ovirt-node-2.3.0-8.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 824621 (view as bug list)
Environment:
Last Closed: 2012-07-19 14:13:06 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
VMMigError (8.78 KB, application/x-gzip)
2012-05-18 14:25 UTC, shine
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 742365 1 None None None 2021-01-20 06:05:38 UTC
Red Hat Bugzilla 824053 0 unspecified CLOSED dhclient-script should honor PEERDNS on quit 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHBA-2012:0741 0 normal SHIPPED_LIVE ovirt-node bug fix and enhancement update 2012-07-19 18:10:46 UTC

Internal Links: 742365 824053

Description shine 2012-05-18 14:25:51 UTC
Created attachment 585425 [details]
VMMigError

Description of problem:
VM migration failed with empty resolv.conf after registered to RHEVM

Version-Release number of selected component:
rhev-hypervisor6-6.3-20120516.0.el6

How reproducible:
100%

Not Regression

Priority: High

Steps to Reproduce:
1. install rhev-hypervisor6-6.3-20120516.0.el6 to the machine
2. register it to rhevm
3. find the /etc/resolv.conf was empty
4. Connect to NFS storage, and create VMs on the RHEVH host


Actual results:
resolv.conf is empty, which results in DNS error and vm migration failure.[migerrorvdsm.log]
But the resolv.conf wouldn't be empty, after rebooted the rhevh. Then vm migration still failed.
If the hostnames of srchost and desthost are different, I modified the host-name setted on rhevm as the hostname of RHEVH, the migration is successful.[pic successfulmig.png]


Expected results:
vm migration should be successful.


Additional info:

Comment 1 Guohua Ouyang 2012-05-21 10:39:09 UTC
the root cause is that dns is removed after register to rhevm, to reproduce this can specify the dns on tui manually and then register to rhevm.

set priority to urgent to highlight this issue.

Mburns, 
Please help assign the bug to vdsm component it it's not owned by ovirt-node.

Comment 4 Mike Burns 2012-05-21 21:06:58 UTC
I looking into this some more and it's not exactly vdsm causing the problem (though that mght be where the fix is).

Sequence:

configure network
set different dns
apply changes
drop to shell
check /etc/resolv.conf -- setup correctly
service network restart
check /etc/resolv.conf -- empty


The rhevm registration does a service network restart which might be where we need to fix this

Comment 5 Fabian Deutsch 2012-05-22 08:43:51 UTC
Mike,

I could not reproduce the problem by following your steps.
In my tests /etc/resolv.conf was never empty. I configured the NIC with DNS and used the IP of a non-existent DNS server.

Comment 6 Fabian Deutsch 2012-05-22 09:56:18 UTC
Okay, I finally could reproduce this.

Comment 7 Fabian Deutsch 2012-05-22 13:38:29 UTC
The problem is the following:

The network is configured using DHCP, dhclient creates a copy of the original (a) /etc/resolv.conf in e.g. (b) /var/lib/dhclient/resolv.conf.predhclient.breth0 .
When dhclient is shut down, it overwrites /etc/resolv.conf with (b), thus, any changes that happened during the lifetime of dhclient to /etc/resolv.conf are lost.

If /etc/resolv.conf was empty before dhclient was started, and a DNS server is manually given in the TUI while dhclient is running, then - when a network restart happens - /etc/resolv.conf will be empty again and we've got this problem.

AFAIU the same applies to the ntp configuration.

Comment 11 Fabian Deutsch 2012-05-22 16:02:15 UTC
The following patch should fix this problem:
http://gerrit.ovirt.org/4674

Comment 14 yuanquan chen 2012-05-28 10:28:25 UTC
Verified with rhevh-6.3-20120523.1. the DNS won't be removed after restarting network service. It also successes to register to rhev-m and do vm migration.

Comment 15 Stephen Gordon 2012-06-14 15:33:15 UTC
The tech note for this was covered in a related bug, so no technical note required for this one.

Comment 17 errata-xmlrpc 2012-07-19 14:13:06 UTC
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.

http://rhn.redhat.com/errata/RHBA-2012-0741.html


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