Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 723115

Summary: kernel params are not always removed from line after registering to RHEV-M
Product: Red Hat Enterprise Linux 6 Reporter: Pavel Stehlik <pstehlik>
Component: ovirt-nodeAssignee: Mike Burns <mburns>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 6.1CC: apevec, cshao, gouyang, leiwang, mburns, moli, ovirt-maint, ycui, yeylon
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: ovirt-node-2.0.2-0.10.gitee3b50c.el6 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 737722 (view as bug list) Environment:
Last Closed: 2011-12-06 19:18:28 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 737722    
Attachments:
Description Flags
Patch none

Description Pavel Stehlik 2011-07-19 06:25:41 UTC
Description of problem:
 This BZ is holder for issue - when I installed rhev-h-6.2-0.5.iso, I used management_server=IP:8443 & management_server_fingerprint=my:fp:... clauses. In this case vdsm-reg fetch wrong ca.crt (it looks it at   http://IP:8443/ca.crt). After approval the install failed. Then I changed port => 8080 in vdsm-reg.conf & restart vdsm-reg service, then host was installed successfully. 
 The problem is, that kernel param management_server & management_server_fingerprint stays there.

Version-Release number of selected component (if applicable):
rhev-h-6.2-0.5.iso

How reproducible:
100%

Steps to Reproduce:
1. pls read description
2.
3.
  
Actual results:


Expected results:


Additional info:

Comment 2 Mike Burns 2011-07-22 19:39:58 UTC
The only options that are removed from the boot command line are ones that are explicitly handled in ovirt-early.  The management_server option is part of the vdsm plugin and I'm not aware of the management_server_fingerprint option at all.  

Having these in the boot line does not hurt anything.  

The tricky thing is that there isn't a way for something like vdsm to tell ovirt what parameters it's expecting.

One possible solution:  

vdsm (or other plugins) write a file in /etc/ovirt-early.d called something like
vdsm-ignore-parameters

When processing commandline arguments, ovirt-early, reads all files that match the pattern /etc/ovirt-early.d/*-ignore-parameters and ignores all entries in those files.  

Alan,

Does the above make sense for the plugin architecture?

Comment 3 Alan Pevec 2011-07-25 00:05:50 UTC
management_server_fingerprint is new vdsm-reg parameter, for checking rhevm cert

> Having these in the boot line does not hurt anything.  

Unless you want to change it: vdsm-config always overwrites values in vdsm-reg.conf by those specified in boot parameters.
 
> Does the above make sense for the plugin architecture?

Yeah, we'll need something like you described, but for now it's not a high priority.

Comment 6 Mike Burns 2011-09-12 23:19:04 UTC
Created attachment 522830 [details]
Patch

Add a directory on ovirt-node called /etc/ovirt-commandline.d where plugins and/or packages can place a file containing a list of command line variables to ignore when setting up the boot params for subsequent boots.

Comment 7 Alan Pevec 2011-09-13 06:40:16 UTC
-            if ! grep -qw /etc/ovirt-commandline.d/*; then
+            if ! grep -qw $varname /etc/ovirt-commandline.d/*; then

Comment 8 Mike Burns 2011-09-13 10:54:04 UTC
(In reply to comment #7)
> -            if ! grep -qw /etc/ovirt-commandline.d/*; then
> +            if ! grep -qw $varname /etc/ovirt-commandline.d/*; then

Oops, dumb mistake, fixed in git but no need to post new patch

Comment 12 Mike Burns 2011-10-03 16:12:15 UTC
Add additional cleanup patch to suppress errors if there are not files in /etc/ovirt-commandline.d


diff --git a/scripts/ovirt-early b/scripts/ovirt-early
index df3b0cd..28ebd05 100755
--- a/scripts/ovirt-early
+++ b/scripts/ovirt-early
@@ -653,7 +653,7 @@ start_ovirt_early () {
             *)
             # check the params to be ignored before adding to bootparams
             varname=${i%=*}
-            if ! grep -qw $varname /etc/ovirt-commandline.d/*; then
+            if ! grep -qw $varname /etc/ovirt-commandline.d/* 2>/dev/null; then
                 bootparams="$bootparams $i"
             fi
             ;;

Comment 18 errata-xmlrpc 2011-12-06 19:18:28 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-2011-1783.html