For large environments, highly-secure environments, and many other situations, a hosted arrangement is not feasible. Companies need a way to attach subscriptions and deliver software content locally. In that case, an organization entry with an on-premise subscription management application such as Red Hat Satellite is added to the inventory in RHSM. The list of attached subscriptions is defined in a manifest, which outlines all of the subscriptions, products, and content repositories for that organization.The subscription management application then directly manages all of the systems and units at its local site. This has performance benefits by lowering bandwidth, and it offers significant management benefits to administrators by allowing local and flexible control over subscription management.

Before you can register your systems with RHSM, you need an active subscription and available entitlements. Subscriptions can be purchased through the Red Hat Store or by contacting Sales directly. After purchasing, you may need to wait 10 minutes before the subscriptions show up in the Customer Portal. After you successfully purchase the subscriptions you need to manage your Red Hat products and services, you register the subscriptions with RHSM. Finally, you attach individual subscriptions and entitlements to the systems that can use them.

Red Hat Subscription Management uses specific terminology around the registration, usage, and tracking of your subscriptions.

Use the 'register' command while logged in with your Customer Portal credentials. When the system is successfully authenticated, it echoes back the newly-assigned system inventory ID and your Customer Portal account.

[root@server1 ~]# subscription-manager register --username admin-example --password secret

The system has been registered with id: 7d133d55-876f-4f47-83eb-0ee931cb0a97+'

[root@server1 ~]# subscription-manager register --username admin-example --password secret --auto-attach

Administrators may want to attach and track subscriptions for a system with limited connectivity or inconsistent access to the Internet. To register an offline or "air-gapped" system, you need to manually create a system profile using Red Hat Subscription Management in the Customer Portal.

The only thing required to unregister a machine is to run the unregister command. This removes the system’s entry from the subscription service, removes any subscriptions, and, locally, deletes its identity and subscription certificates. From the command line, this requires only the 'unregister; command.

# subscription-manager unregister

There are times when the local registration and subscription information could be lost or corrupted. There could be a hardware failure or system crash. Or other IT considerations may require that a system be moved to a different machine. Whatever the reason, the local subscription configuration is lost.

A system can be registered against an existing system entry in the Red Hat subscription service, which essentially restores or reregisters that system. The reregister operation uses the original system ID with the registration request, so that all of the previous subscriptions associated with the system entry are restored along with the registration.

Red Hat Subscription Manager has specific commands that can be used to help maintain your systems using the command line interface.

To manage subscriptions, administrators need to know both what subscriptions are currently attached to a system and what subscriptions are available to the system. You can manage your usage from the Customer Portal from the Subscription Utilization page.

To manage subscriptions from the command line:

[root@server1 ~]# subscription-manager list --consumed

+-------------------------------------------+
		Consumed Product Subscriptions
+-------------------------------------------+


ProductName:        	Red Hat Enterprise Linux Server
ContractNumber:     	1458961
SerialNumber:       	171286550006020205
Active:             	True
Begins:             	2009-01-01
Expires:            	2011-12-31

[root@server1 ~]# subscription-manager list --available --all

+-------------------------------------------+
		Available Subscriptions
+-------------------------------------------+


ProductName:            RHEL for Physical Servers
ProductId:              MKT-rhel-server
PoolId:                 ff8080812bc382e3012bc3845ca000cb
Quantity:               10
Expires:                2011-09-20


ProductName:            RHEL Workstation
ProductId:              MKT-rhel-workstation-mkt
PoolId:                 5e09a31f95885cc4
Quantity:               10
Expires:                2011-09-20

The registration process automatically begins creating and maintaining a package list for the given subscription service. Since package lists are a core aspect of subscription maintenance, this data collection cannot be suspended. If it is necessary to prevent data collection on the system, then remove the system from the subscription management service.

New to Red Hat Enterprise Linux, system administrators can use System Purpose to record the intended use of a Red Hat Enterprise Linux 8.0 Beta system by the organization. When a system’s purpose is recorded, entitlements are automatically attached.

You can enter System Purpose data in the following ways:

You can configure the following components:

Modules are a package organization mechanism which enables the user to choose from multiple versions of package sets. Modules combine features of groups and repositories. For example, it would allow a network to more frequently update some systems with the most recent version of one piece of software while keeping the version consistent on others.

The Anaconda installer can enable module streams and install module profiles.

module --name=NAME [--stream=STREAM]

You may create new users in your organization to have different permissions if you are an organization administrator.

If the permissions a pre-existing user has need to be updated or are no longer appropriate, you can update them at any time.

The organization ID is a Candlepin-specific identifier and is separate from your Red Hat and Oracle account numbers. They are necessary for using activation keys.

When you purchase a subscription, you receive a 16-digit subscription number. You then enter that number in the Customer Portal to redeem the subscription.

Errata notifications are set as a preference for the user account, not for an individual system. When RHSM checks for potential errata updates, it checks the entire inventory, not specific systems. An errata notification is sent if any registered system is affected, but the email does not list what systems are actually affected.

If you see applicable errata displayed in RHSM but have no yum updates available, it can mean one of a couple of settings are not correct.

# rm -f /var/lib/rhsm/packages/packages.json
# service rhsmcertd stop
# rhsmcertd --now
# yum update

Updating the facts resends the information about the system to the Red Hat subscription service so that it can update the list of subscriptions which match the system architecture. Updating the facts is a recommended after hardware upgrades or other important system changes.

Although credentials are not normally required with the identity command, using the '--force' option will require the username and password and will cause the Subscription Manager to prompt for the credentials if they are not passed in the command. This can be helpful if the identity certificate needs to be regenerated using a different Red Hat account than the original registration.

Subscription entitlements do not get used until they are attached to a system that needs it. Attaching a subscription is the next step after registration to RHSM.

If a subscription has expired or you want to clear up an entitlement for another system, you can remove a subscription from a system manually.

Removing a system from your account destroys it completely. You can no longer register or attach subscriptions to it, and it no longer receives applicable erratum notifications. Having systems that are no longer active on your account can cause backlog and lag issues when performing account-wide maintenance.

Creating a new subscription allocation allows you to set aside subscriptions and entitlements for a system that is currently offline or air-gapped. This is necessary before you can download its manifest and upload it to a system.

Once an allocation is created, you can add the subscriptions you need for the system to run properly once it goes online. This step is necessary before you can download the manifest and add it to the host system.

Once an allocation is created and has the appropriate subscriptions on it, you can download the manifest from RHSM.

A system needs a manifest to connect to RHSM. If you used a subscription allocation to create the manifest, you need to download the manifest first and then upload it to the host system. This situation is useful for systems that are offline or air-gapped.

Supported virtualization platforms to which a Virtual Data Center (VDC) subscription can be applied are:

A VDC subscription applies only to a hypervisor’s guest virtual machines, not the hypervisor itself. For all virtualization platforms which require a Red Hat Enterprise Linux hypervisor, the hypervisor requires its own subscription.

As hypervisors do not natively report guest mappings to Red Hat Satellite or the Red Hat CDN, the virt-who service has been created to ensure virtual guests consume the proper Red Hat subscriptions. The virt-who agent interrogates the hypervisor infrastructure and provides the host/guest mapping to the subscription service.

After successfully installing, establish connections between the virt-who daemon and your hypervisors.

Subscription relationships have a lot of potential flexibility. Some subscriptions can be applied to a physical machine or to a certain number of virtual machines, while others can be applied to a physical host and then inherited by guests.

For subscriptions to be managed effectively, there has to be an internal awareness in the subscription service of the relationships between hosts and guests. This way, a subscription service can properly attach a single physical subscription to a physical host and then apply an included virtual subscription to its guest (for example), rather than consuming two physical subscriptions for each instance.

This association is done by extracting a universally unique identifier for each guest and associating it with its hypervisor. These UUIDs are part of the system facts for each virtual system.

The hypervisor is registered first with the subscription service, and then a related process on the system scans for any guests and submits the discovered UUIDs to the subscription service. This is done through the 'libvirt' process when the 'virt-who' command is run.

There are three factors that must be true for the subscription service to recognize the host/guest association and properly attach subscriptions:

Virtual machine hypervisors use the same registration process as other systems:

# sudo subscription-manager register

Subscriptions, preferences, and autoattach settings for both virtual hosts and virtual guests are configured the same as for physical systems and other types of consumers.

There are two things to be aware of when using subscriptions in virtual environments.

Guests can inherit some subscriptions from their host. This means that it is not necessary to attach subscriptions to those systems for some products and that more products and content may be available to a system than what is directly attached to it.

The quantity of subscriptions required for a virtual guest is lower than for a physical machine. For physical machines, subscriptions must cover the physical attributes of the machine, such as the number of sockets or cores. Subscriptions are always applied in sets of two to cover pairs of sockets or cores, and those subscription pairs must be attached to cover all sockets and cores. (For example, a four socket system requires two sets of two subscriptions).

However, for virtual guests, those physical attributes do not apply when counting subscriptions. Only a quantity of one is ever required to cover a virtual guest.

There is a specific subscription available for data centers which registers a physical system as a hypervisor and then allows an unlimited number of virtual guests to be installed and registered on that system. That physical system can be a RHEL system running RHEV or Xen, or it can be a non-Linux system, running VMware or HyperV. The configuration does not matter as with running any virtualized environment, there simply must be one RHEL system to run the virt-who process to create the host/guest mapping.

For each physical host in the environment:

Individual configuration files are recommended for each hypervisor or virtualization manager as it makes troubleshooting easier. For example, if you suspect a hypervisor is causing a problem, you can move that hypervisor�s configuration file to another directory, stopping virt-who from querying it and so eliminating it from the problem’s scope.

If you have multiple hypervisors, virt-who queries each in parallel. This reduces the chance of virt-who’s queries being stopped or delayed because of an unresponsive hypervisor.

A single virt-who instance can connect to virtualization platforms of multiple supported technologies. Individual configuration files are recommended for each platform.