Bug 1235965

Summary:	Regenerate initramfs during installation to include multipath related configuration
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Fabian Deutsch <fdeutsch>
Component:	ovirt-node	Assignee:	Fabian Deutsch <fdeutsch>
Status:	CLOSED ERRATA	QA Contact:	cshao <cshao>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.5.1	CC:	bgraveno, fdeutsch, gklein, lsurette, pdwyer, ycui, ykaul
Target Milestone:	ovirt-3.6.0-rc
Target Release:	3.6.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovirt-node-3.3.0-0.4.20150906git14a6024.el7ev	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-03-09 14:31:43 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Node	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1191401, 1204212

Description Fabian Deutsch 2015-06-26 08:39:42 UTC

Description of problem:
Currently the initramfs used to boot RHEV-H during installation and runtime is a pregenerated initramfs generated at build time.

The benefit of this approach is, that the initramfs is never touched, and thus we can be sure that it works for the customer, if it worked in testing.

The drawback is that some host- or site-specific configurations are not integrated into the initramfs during installation time.
The most obvious topic where this is highly visible is multipath.
The wwids and the exact multipath configuration must be part of the initramfs to ensure that the multipath configuration is setup correctly during the early boot.

This is most important for multipath devices which are used for booting. If an incorrect multipath configuration is used in initramfs, then the aggregation of the multiple paths (of the device used for booting) into one logical multipath device can fail.

To fix this, this bug is about rebuilding the initramfs during installation, to include the host-specific wwids and multipath configuration, at installation time.

The risk is that this creation will fail. Furthermore the initramfs will be different on each host.

Comment 1 Ying Cui 2015-06-29 08:44:13 UTC

Firstly, QE can not reproduce these three bugs (bug 1191401, bug 1204212, and bug 1225182) listed above.

Secondly, for further verify this bug:
 a) we need to test generate new initramfs during clean install/reinstall/upgrade, the output should be included the following to ensure the code be executed.
        LOGGER.info("Preparing to regenerate the initramfs")
        LOGGER.info("The regenreation is performed in-place, "
                    "the existing initrd will be overwritten")
 b) wwid= will not appear on kernel cmdline anymore.
 c) so far the scripts/ovirt-node-update-initramfs is not used by others, and it should be .py 

Fabian, QE can verify this bug according to patches, but we can not fully verify the bug 1191401, bug 1204212, and bug 1225182.

Comment 2 Ying Cui 2015-06-29 08:44:35 UTC

qa_ack+ on this bug only.

Comment 3 Fabian Deutsch 2015-06-29 10:23:36 UTC

(In reply to Ying Cui from comment #1)
> Firstly, QE can not reproduce these three bugs (bug 1191401, bug 1204212,
> and bug 1225182) listed above.
> 
> Secondly, for further verify this bug:
>  a) we need to test generate new initramfs during clean
> install/reinstall/upgrade, the output should be included the following to
> ensure the code be executed.
>         LOGGER.info("Preparing to regenerate the initramfs")
>         LOGGER.info("The regenreation is performed in-place, "
>                     "the existing initrd will be overwritten")

These lines should appear in the logfiles.

>  b) wwid= will not appear on kernel cmdline anymore.

Correct. The wwid= commandline is not needed anymore, because the wwids are now kept inside the initramfs.

>  c) so far the scripts/ovirt-node-update-initramfs is not used by others,
> and it should be .py 

The toll will not have the .py suffix. The intention of this tool is to give GSS or users the opportunity to rebuild the initramfs if needed (after doing some updates in /etc).

> Fabian, QE can verify this bug according to patches, but we can not fully
> verify the bug 1191401, bug 1204212, and bug 1225182.

Yes. I understand that the bugs above can not be verified.

The most important thing that needs to be done from the QE POV on this bug is, to ensure that all existing multipath devices continue to work.

Comment 6 cshao 2016-02-17 08:40:33 UTC

Hi fabiand,

Could you point me how to fully verify this bug?

Thanks!

Comment 7 Fabian Deutsch 2016-02-17 19:46:22 UTC

Test steps:


1. Install RHEV-H on a multipath host
   Remember the WWID/serial of the boot device
2. After reboot: lsinitrd <initrdfile> -f /etc/multipath/wwids

After 2: WWID/serial of boot device is in wwids file.

Note: <initrdfile> is likely /run/.initramfs/live/initrd*

Comment 8 cshao 2016-02-18 08:41:20 UTC

(In reply to Fabian Deutsch from comment #7)
> Test steps:
> 
> 
> 1. Install RHEV-H on a multipath host
>    Remember the WWID/serial of the boot device
> 2. After reboot: lsinitrd <initrdfile> -f /etc/multipath/wwids
> 
> After 2: WWID/serial of boot device is in wwids file.
> 
> Note: <initrdfile> is likely /run/.initramfs/live/initrd*

Fabiand, thank you very much:)

Test version:
rhev-hypervisor7-7.2-20160212.0
 ovirt-node-3.6.1-6.0.el7ev.noarch

Test steps:
1. Install RHEV-H on a multipath host
2. Reboot host
3. Run below command:
# lsinitrd /run/initramfs/live/initrd0.img -f /etc/multipath/wwids
cat: write error: Broken pipe
# Multipath wwids, Version : 1.0
# NOTE: This file is automatically maintained by multipath and multipathd.
# You should not need to edit this file in normal circumstances.
#
# Valid WWIDs:
/36782bcb03cdfa200174636ff055184dc/
/36005076300810b3e0000000000000022/
/36005076300810b3e0000000000000023/
/36005076300810b3e0000000000000024/
4. Check /etc/multipath/wwids

Test result:
After 3: WWID/serial of boot device is in wwids file.

According #c7, the bug is fixed, change bug status to VERIFIED.

Comment 11 errata-xmlrpc 2016-03-09 14:31:43 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.

https://rhn.redhat.com/errata/RHBA-2016-0378.html