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.
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.
@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
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.
Sandro, Will we use kpatch in 4.2.7? Thanks.
(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.
Still need more research, so pending provide qa_ack+ flag.
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.