Hide Forgot
1. Proposed title of this feature request? Multipath configuration during RHEL8 inplace upgrades should be supported. 2. Who is the customer behind the request? Account: 748231 TAM customer: Yes SRM customer: Yes Strategic: Yes748231 3. What is the nature and description of this request? Following the second RHEL8 town hall, the customer has discovered that multipath is not supported for in-place upgrades. They would like to request that this is supported. 4. Why does the customer need this? (List the business requirements here) A good proportion of their estate currently uses either RAID (desktops) or multipath (servers) as part of their configuration. It would be great if the in-place upgrade tool supported these scenarios. 5. How would the customer like to achieve this? (List the functional requirements here) - iptables packages should be removed during upgrade - iptables configuration should be migrated to nftables without requiring user intervention 6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented. Perform an inplace upgrade, and check post-upgrade that multipath functionality mirrors the previous configuration. 7. Is there already an existing RFE upstream or in Red Hat Bugzilla? Not that I can find. 8. Does the customer have any specific timeline dependencies and which release would they like to target (i.e. RHEL6, RHEL7)? RHEL 8 GA 9. Is the sales team involved in this request and do they have any additional input? No. 10. List any affected packages or components. device-mapper-multipath 11. Would the customer be able to assist in testing this functionality if implemented? Yes
I am seeing a problem with the current internal Leapp repos and a multipath configuration when upgrading from RHEL-7.6 to 8.0. The Upgrade RAMDISK fails to activate the system root devices and drops into the dracut shell. The cause isn't immediately clear but I've not carried out any real debugging yet. The host configuration is simple: one VirtIO disk for /boot, and a pair of iSCSI targets served by LIO/targetcli. Installation of RHEL7.6 to this set up proceeds as expected, leaving the volume group containing the root file system on the two multipath devices. The initial phase of Leapp seems to run as normal, but then fails booting the upgrade image.
I've been able to reproduce the problem with booting into a leapp upgraded rhel8 system. Using iscsi devices like Comment 13 fails because the network isn't set up in time. But even if you can access the devices, multipath still fails because the multipath dracut module isn't present, but multipath is set up to run on the root and boot devices. If I mount all the missing filesystems and exit the emergency shell, and remake the initramfs with # dracut -f --add multipath everything works fine. So I believe that to fix this, the leapp tool needs to include the multipath dracut module in the initramfs it creates, if the rhel7 initramfs was including it. This bug should probably be reassigned to the leapp team, but I'm not sure what Component that goes under.
A note from email exchange... I’ll ask Ben if he can come up with a simple command / script that would detect if multipath is in use on the RHEL7 system before upgrade. It might be as simple as checking the DM tables and grepping for ‘multipath’. # Tells you whether there is an active multipath instance on the machine e.g.> dmsetup table | grep multipath brassow That will pull in the multipath dracut module when it's not really needed (for non system directory cases). Instead you can just check if it's in the current initramfs. lsinitrd | grep "^multipath" should work for that. -Ben
I've been instructed that the right location for this bug is RHEL7, leapp-repository. Switching there.
I'm assigning this back to the leapp team, since the multipath actor work has been submitted https://github.com/oamg/leapp-repository/pull/473
Thanks Ben. The support for multipath has been released downstream in Leapp version 0.10.0: https://access.redhat.com/errata/RHBA-2020:1959.