Bug 1308544

Just to document the "workarounds" that usually (not absolute, but nearly always) work ...


Option 1 - Single Activation Key - register (w/host-key), remove, re-attach ...

  # subscription-manager register --org="Default_Organization" --activationkey="ak-x64elX_host"
  # subscription-manager remove --all
  # subscription-manager attach --auto


Option 2 - Dual Activation Keys - register (w/host-key), unregister, re-register (w/guest-key)

  # subscription-manager register --org="Default_Organization" --activationkey="ak-x64elX_host"
  # subscription-manager unregister
  # subscription-manager register --org="Default_Organization" --activationkey="ak-x64elX_guest_typeY"


The 1st command, using a "host key" that _forces_ a subscription to be Virtual Datacenter or other "unlimited guest," causes two (2) entitlements to be consumed ...
 1)  For the guest, which seemingly gets "entitled first"
 2)  For the ESX or other, non-RHEL HyperVisor host, which seemingly gets "entitled second"

It seems there is an issue with how Katello-Foreman and Candlepin interact, wherasa the "guest" is in the state diagram or other, logical flow, before the host -- which might be okay with Red Hat HyperVisors, but not others where Subscription-Manager/Satellite is not directly making API calls to the host environment (e.g., vCenter in the case of ESX).

The 2nd and 3rd commands depend on whether or not the guest re-attaches to the correct entitlement/subscription.

If so, the #1 option can be used -- remove then auto-attach, which only affects the guest.

If not, or the guest needs to have specific content views, repos, etc... enabled, then the #2 option is _required_.  Unregister, which only affects the guest, and then re-active using a "guest" specific type (for the systems use/subscriptions) activation key with the appropriate channels, content views, etc... required.

FTR, I wrote and am currently using https://github.com/evgeni/katello-attach-subscription as an workaround.

Interesting workaround.

I'm hoping to have Satellite 6 on-line at my new client, who also uses VMware (like my prior client), soon to test.  Right now my new client is only using the upstream components (Katello, Foreman, Pulp, et al.), so no Candlepin.

The only thing I want to point out, if I'm reading the Ruby correctly, is that Red Hat will have customers with HyperVisors that have no RHEL guests.

I.e., It is not uncommon and, in fact, quite common for most of Red Hat customer's to be running a non-RHEV HyperVisor, like VMware, because their Windows division specified the requirements, and the Linux team has been moved on to it without any input.  So ...

E.g., RHEL guests are often only running on a subset of the total HyperVisors, especially if it's the minority OS on VMware at the customer.

Q1:  In those cases, how well does that workaround work for HyperVisors with no guests?  Or, more importantly yet ...

Q2:  The cases when a RHEL guest moves from the HyperVisor, and is no longer running on the HyperVisor, and possibly no RHEL guests on the HyperVisor?

These are "real world" questions customers are asking with virt-who, especially with Satellite 6 / Katello.  I will also include a non-technical, real-world entitlement scenario / viewpoint from the common customer.

<non-technical>
I'm not with Product Management or Entitlement Enforcement, but I've always felt our best move with Candlepin et al. is to reconcile HyperVisor entitlement night -- once per day -- and give our customers the power to self-report their "worst case" of HyperVisors in use on one night over, say, a quarter.

E.g., say a customer only has 16 HyperVisors in use, on average, but due to loads, there were 2 nights in the quarter when they had 20 HyperVisors utilized.  We should give them the tools to self-report that they need to license for 20.  I also think we should be flexible enough to allow up to 25% more usage, which then they self-report for their next check-up or renewal (usually quarterly with their SA and/or TAM) with their Red Hat representative, which only helps Red Hat's bottom line.

I understand this is unrelated to the ticket, but I'm including it regardless.  I've always been about empowering the customer to self-report, as they are Red Hat's best customers and only often argue to buy more Red Hat.
</non-technical>

Hi,

(In reply to Bryan J. Smith from comment #10)

> The only thing I want to point out, if I'm reading the Ruby correctly, is
> that Red Hat will have customers with HyperVisors that have no RHEL guests.

you can filter those Hypervisors both in virt-who (see filter_host_uuids, exclude_host_uuids in virt-who-config(5)) and in katello-attach-subscription (see https://github.com/evgeni/katello-attach-subscription: "Each subscription hash has an hostname entry which will be used as an regular expression to match the hostname of the content host in Katello"). or you could limit your vCenter user to only see Linux Hypervisors.

> Q1:  In those cases, how well does that workaround work for HyperVisors with
> no guests?  Or, more importantly yet ...

Works just fine with my customers :)

> Q2:  The cases when a RHEL guest moves from the HyperVisor, and is no longer
> running on the HyperVisor, and possibly no RHEL guests on the HyperVisor?

Well, you'd need one sub for every Hypervisor that can *potentially* run RHEL guests as a RHEL guest might be migrated to such a Hypervisor at some point in time.

> These are "real world" questions customers are asking with virt-who,
> especially with Satellite 6 / Katello.  I will also include a non-technical,
> real-world entitlement scenario / viewpoint from the common customer.

I am not aware of any good customer-facing docs on this, I guess a BZ is the best way to get it done.

> Well, you'd need one sub for every Hypervisor that can
> *potentially* run RHEL guests as a RHEL guest might be
> migrated to such a Hypervisor at some point in time.

That's my concern.

Why can't we reconcile each day how many HyperVisors were actually used?
Not how many could be *potentially* used?

We should *always* approach this from a customer-side, self-reporting view.
Virtually all of Red Hat's customers like to self-report and pay money.

Or should I flip this to say ...

Red Hat now the virt-who solution and tracking in Satellite 6 utterly confuses them to the point they do *not* understand what they are using.

Most Red Hat customers just want to know what they are *actually* using.  Why?  Again, they self-report.  They want to be compliant.  They want Red Hat to continue.  They know if they cheat Red Hat, they are only cheating themselves and their future with the platform.

Hence why the tool should work from a customer reporting standpoint, one they can understand.

*** Bug 1353697 has been marked as a duplicate of this bug. ***

An addendum from a customer to this RFE is to think about some automation, to let satellite spot cluster with RHEL VMs in and then attach:

1. Proposed title of this feature request
Assign automatically subscription to all hypervisor of a cluster if RHEL guests are present in the cluster.

3. What is the nature and description of the request? 
This case is linked to #1307036
We need virt-who to guess if there are RHEL guest into vmware cluster.
If there is any ([1..N]) virt-who need to automatically attach subscription to all of the hosts present in the cluster.

Looking at a duplicate bug (https://bugzilla.redhat.com/show_bug.cgi?id=1353697) it seems like the expected behaviour is to have the following:

1) Be able to assign subscriptions to all newly discovered hypervisors.
2) Be able to assign subscriptions only to hypervisors with RHEL guests.
3) Have a job which runs on a scheduled basis which does the following:
a) Remove subscriptions from hypervisors with no guests
b) Adds subscriptions to hypervisors with guests

(In reply to Bryan Kearney from comment #19)
> Looking at a duplicate bug
> (https://bugzilla.redhat.com/show_bug.cgi?id=1353697) it seems like the
> expected behaviour is to have the following:
> 
> 1) Be able to assign subscriptions to all newly discovered hypervisors.
> 2) Be able to assign subscriptions only to hypervisors with RHEL guests.
> 3) Have a job which runs on a scheduled basis which does the following:
> a) Remove subscriptions from hypervisors with no guests
> b) Adds subscriptions to hypervisors with guests

This is partially correct, looking at the bugzilla https://bugzilla.redhat.com/show_bug.cgi?id=1353697 .

1) Be able to assign multiple subscriptions to all newly discovered hypervisors. -> note multiple
2) Be able to assign subscriptions only to hypervisors that belong to a cluster with RHEL guests, based on regexp on cluster name. -> belong to cluster and regexp
3) Have a job which runs on a scheduled basis which does the following: -> belong to cluster
a) Remove subscriptions from hypervisors belonging to a cluster with no guests
b) Adds subscriptions to hypervisors belonging to a cluster with guests
c) (a+b) Change subscriptions to hypervisors that changed cluster and have different guests

use cases:

#1 
for multiple subs can be handled through https://bugzilla.redhat.com/show_bug.cgi?id=1344049 as well
use case: 
subscription that are unlimited guest but without smart management. smart management must be added to all of the hosts.

#2 
see also https://bugzilla.redhat.com/show_bug.cgi?id=1307036#c10
Generally, one hypervisor always belong to a cluster.
Sometime, some hypervisor can have 0 RHEL servers associated, but the expectation is that if a vmotion is made, the guest will continue to have a valid subscription.
Also the number of subscription, if the cluster is not taken in consideration, may vary from day to day.

About regexp, the hostname of the hypervisor may be a standard one.
What is usually meaningful is the cluster name.

#3 
one hypervisor with sub 123 is assigned to one cluster.
this sub is standard, and the cluster belong to QA environmnet.
the host move to another cluster (remind that has already one sub, and that hostname do not change).
the hypervisor should drop the sub 123 the standard one, and get the 456, the premium one.

HTH

*** Bug 1307036 has been marked as a duplicate of this bug. ***

*** This bug has been marked as a duplicate of bug 1401106 ***