Red Hat Bugzilla – Bug 528761
Add RHEL-4 KVM Guest and Flex Guest Support
Last modified: 2015-01-04 16:57:13 EST
Description of problem:
Redhat network registration of a fully virtualized guest running Redhat Linux Enterprise ES release 4 update 8 on a host running RHEL 5.4 using KVM fails, despite following the procedure as detailed in Redhat KB article #9933.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install RHEL-5.4 host, with Virtualization entitlement, and configured for KVM
2. Create and install a RHEL-4.x guest
3. Run rhn_register in the RHEL-4.x guest
rhn_register fails, stating that there are were "Insufficient Software Channel Entitlements"
Registration should succeed, because there are less than four virtual guests installed on the fully registered host
Actually, we did not install a fresh RHEL4.x guest, but copied the contents of a running and fully registered and updated physical server into the guest's filesystem, fixed up the hardware information, created a new up2date-uuid, and then tried to register the guest. Guest is i686, host x86_64.
The guest _is_ shown in the Virtualization tab of the host machine's details page in RHN, but registration fails even when using rhnreg_ks.
$ grep -Ei 'kvm|qemu' /usr/share/rhn/* /usr/share/rhn/*/*
returns nothing, whereas
$ grep -i xen usr/share/rhn/* /usr/share/rhn/*/*
finds some matches in /usr/share/rhn/up2date_client/rhnreg.py; so I guess KVM virtualization is currently not supported by the RHN registration, at least when running a RHEL-4.x guest.
KVM is not supported in RHEL4. It has been supported since RHEL 5.3.
Therefore RHEL 4 as KVM should behave as physical machine.
If you disagree please reopen this bug.
If you want implemented as feature for RHEL4 contact support for possibilities.
Sorry, RHEL4.8 as KVM guest is supported scenario.
Hello, any news on this?
It seems to me quite serious as a bug.
1) You advertise unlimited guest support with RH EL AP as Hypervisor platform
2) RH EL 4 is a fully supported OS at least until 2012:
End of Production 3 phase: February 29, 2012
3) Many customers still have RH EL 4 systems (and also RH EL 3, btw)
In my opinion, this is a show stopper for going to virtualize with RH Hypervisor.
This bug was opened more than 4 months ago.....
At least make a note for the product release, before one buys with incorrect assumptions.... not a very polite way of selling (always in my opinion)
Hi Gianluca Cecchi,
This bug is currently aligned to the next major maintenance release cycle for Red Hat Enterprise Linux 4.
I have changed the priority of this bug to reflect what I feel is a more accurate reflection of this bug's impact and it is being re-reviewed. Please open a support ticket and have that aligned to this bug for tracking against your account with Red Hat.
In fact I arrived here due to my opened case that is number 1995370
I have a case on this also, number 1996294.
*** Bug 539361 has been marked as a duplicate of this bug. ***
Giving devel ack as we have patch for RHEL 4's up2date in bug 539361 comment 12.
Fixed in revisions:
Version built: up2date-4.9.1-9.el4
any ideas about when will it be publicly released up2date version 4.9.1-9.el4?
On my rhel 4.8 kvm guest I have 4.8.1-33.el4_8.1 and trying "up2date up2date" I receive the message that is already updated.
Any hope to get it before final 4.9?
(In reply to comment #23)
> any ideas about when will it be publicly released up2date version 4.9.1-9.el4?
> On my rhel 4.8 kvm guest I have 4.8.1-33.el4_8.1 and trying "up2date up2date" I
> receive the message that is already updated.
The package has not been released yet, it hasn't even been tested yet (and we will likely need to respin it anyway).
> Any hope to get it before final 4.9?
Yes, it is tracked to be released as an async errata before RHEL 4.9.
Last fix cause xen info to be sent for kvm guests. This should fix it:
Update up2date-4.8.1-33.el4_8.6 fixes the issue, indeed.
A new run of rhn_register works as expected, the machine is registered as a virtual guest of the host that runs it.
I confirm that deregistering, deleting host from rhn and registering again it (after updating up2date) works for me too.
Verified for both 32bit and x86_64 rhel 4.8 updated guests.
Following is the scenario not fitting the Flex Guests logic:
1. Register 2 guests (of the same host). [consume 2 Management, 2 software channel entitlements]
2. register the host + Virtualization entitle it [consume 3 Management, 1 Virtualization + 2 Flex guest entitlements + 1 software channel entitlement]
3. Delete the host system from the Satellite registration
2 Management entitlements + *2* software channel entitlements + *0* flex guest entitlements ...
So in other words: when the host is removed the guest systems are not returned back to the flex entitlements and start consuming regular software channel entitlements.
err on comment below: in step 1 the guests are consuming the flex guest entitlements - as expected.
This is more of a bug in satellite 5.4 entitlement logic, so garik is going to open another bugzilla for this
related bug#653510 (https://bugzilla.redhat.com/show_bug.cgi?id=653510)
The bug itself (not considering the fact of Comment#39) is fixed:
0. Apply satellite certificate with flex guest entitlements for RHEL4 base channel family.
1. Register virtual guest - appears as virtual system & consumes flex guest entitlements
2. Add the host and entitle it with "Virtualization" - guest does not consume neither normal nor flex.
3. remove host - guests are still shown as virtual (but consuming the normal entitlements - seems like satellite bug, see comments above).
package fixing the issue:
checked for both: i386, x86_64 rhel4 guests.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
On Red Hat Enterprise Linux that is running in a KVM-based fully-virtualized environment, the rhn_register utility no longer fails to register the system with the "Insufficient Software Channel Entitlements" error.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.