Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1562160

Summary: [RFE] Possibility of using kpatch in RHV-H environment.
Product: Red Hat Enterprise Virtualization Manager Reporter: Cal Calhoun <ccalhoun>
Component: rhev-hypervisor-ngAssignee: Yuval Turgeman <yturgema>
Status: CLOSED WONTFIX QA Contact: cshao <cshao>
Severity: medium Docs Contact:
Priority: unspecified    
Version: unspecifiedCC: ccalhoun, cshao, dfediuck, huzhao, lsurette, mgoldboi, mtessun, pstehlik, qiyuan, rbarry, sbonazzo, srevivo, ycui
Target Milestone: ---Keywords: FutureFeature
Target Release: ---Flags: lsvaty: testing_plan_complete-
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-01-15 09:24:12 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: 1653669    

Description Cal Calhoun 2018-03-29 16:21:27 UTC 
Description of problem:
  I have a customer running RHEV-M and they would like to be able to use kpatch or some other means of rebootless kernel patching

  Originally they indicated that they were using RHHI but it was later confirmed that they're using REV-H.

During some discussion on the case, Marc Milgram said:

  "kpatch on products that are not RHEL was brought up in the kpatch meeting today.  The general resolution is:
  In mutable systems (like RHEL, where the OS can be modified), kpatch should work like on RHEL.

  In immutable systems (like RHV-H) where a new version of a package requires an image rebuild, things are a bit different...
   kpatch (hopefully) can be loaded if needed, and a kpatch-patch loaded into the running system.  But the kpatch wouldn't survive a reboot, so a new image would be built with a kernel that includes the patch, so the next time the system boots, it would have the fix.

That said, there should be some documentation created here by someone who is more familiar with RHHI.  Speicifically:
  o kpatching RHV-H
  o Are the gluster guests running off of an immutable image.  Anything else other than RHEL (with some additional bits)?

Any other pieces?

I believe that once we verify that we can run kpatch in these environments, we can support it."


Also on the case, John Call said:

  "Sahina responded to my query on rhev-tech mailing list [1]  With a generally positive sentiment.  But you're right (or cww is right) we don't have the kpatch utility (kpatch.noarch/0.4.0-2.el7_4/@rhel-7-server-rpms) available in the RHV-H repo (rhel-7-server-rhvh-4-rpms)

  Two potential solutions could be:
  1) a support exception for RHV-H aka "thin host" where we side-load the kpatch utility and patches
  2) use RHEL7 aka RHEL-H aka "fat host" and there are no restrictions/concerns (since rhel-7-server-rpms is available)"

  Is this the proper forum to determine if this is supportable?  I don't think this is necessarily applicable only to their case but would be something good to have an answer on in general.
Comment 1 Ryan Barry 2018-03-29 18:10:26 UTC 
We can ship kpath in the RHVH optional channel, similar to tooling for systemtap/etc for CEE.

RHVH 4.x is not immutable, and the kernel survives reboots.

I've never used kpatch, but I'd suggest grabbing kpatch and an appropriate payload, then testing. I'm also happy to do this if you can point me to resources.

If it works (and I'd expect it to), we can definitely ship this in the optional channel, as long as we have a multi product erratum for it.
Comment 2 Cal Calhoun 2018-05-01 14:09:03 UTC 
@Ryan,
I don't see where you've had an opportunity to test this.  I don't have any idea where the necessary resources would be.  Is there someone I can talk to to get you what you need?
-Cal
Comment 3 Ryan Barry 2018-05-01 14:11:53 UTC 
I haven't tested yet, Cal, which is why it's targeted to 4.2.4

I'm finding a member of the kpatch engineering team so they can point me at files we can use.
Comment 4 cshao 2018-09-04 06:46:20 UTC 
Sandro,

Will we use kpatch in 4.2.7?

Thanks.
Comment 5 Sandro Bonazzola 2018-09-20 05:50:51 UTC 
(In reply to cshao from comment #4)
> Sandro,
> 
> Will we use kpatch in 4.2.7?
> 
> Thanks.

I'm moving this out to 4.2.8.
Comment 6 cshao 2018-12-20 03:17:44 UTC 
Still need more research, so pending provide qa_ack+ flag.
Comment 7 Martin Tessun 2019-01-15 09:24:12 UTC 
After reviewing this, I cannot see any reason for having kpatch in a RHVH environment. The kpatch is meant to be used for systems that can't be rebooted (due to the services running on it), but need to be secured.

The first assumption (cannot be rebooted) is never true for a RHVH environment, as you always can migrate the workload off the system.

As such closing this won't fix. Please reopen, if you have some further justification for this feature.