To register your Red Hat Enterprise Linux (RHEL) systems and access the content associated with your subscriptions, you must log in to Red Hat with an account that is associated with those subscriptions.

A Red Hat account is used to identify and authenticate you to Red Hat. It provides you with access to Red Hat applications and services, purchasing capabilities, communities, support, information, and other benefits.

Red Hat accounts are available in two different types:

If you meet any of the following criteria, you already have a Red Hat account:

It is possible that you could have both a corporate and a personal account, and that you use each for different purposes. It is also possible that you are unsure which type of account to use to register systems and install subscriptions, or even if you have an account. However, if your company is using Red Hat software to power enterprise-level solutions, it is likely that it has one or more corporate accounts and organizations to acquire and manage that software.

If you need more information about Red Hat accounts and how they should be used to register systems, you should first discuss your options with internal contacts in your company before proceeding with Red Hat account creation. If you have additional questions, contact Red Hat customer service for assistance.

Simple content access provides an improved subscription experience that removes many of the time-consuming and complex business processes associated with the older Red Hat entitlement-driven enforcement model. The simple content access tool removes the need to use an entitlement to attach a subscription to a system before you can access Red Hat subscription content on that system.

In the entitlement-based subscription model, an entitlement is one of a predefined number of allowances that is used during the registration process to assign, or attach, a subscription to a system. The entitlement-based subscription model is now deprecated and is superseded by the access-based subscription model of simple content access. In the access-based subscription model, access to subscription content is provided by the existence of a valid subscription and registration of the system.

By using simple content access, you can more easily consume subscription content and reduce the complexity of your subscription management workflow. Instead, if you have access to a valid subscription, you can register a system and then consume the subscription content on that system, in a process that is commonly referred to as the “register and run” experience.

The subscriptions service and simple content access are designed to work together to simplify and streamline the overall subscription experience. By removing the need to attach subscriptions at the system level, simple content access reduces complexity and saves time when you are adding, removing, and renewing subscriptions. By offering visibility into subscription usage, the subscriptions service eliminates manual subscription management and enables account-wide governance of your subscriptions.

The subscriptions service in the Red Hat Hybrid Cloud Console is a dashboard-based, Software-as-a-Service (SaaS) application that enables you to view subscription usage in your Red Hat account. It provides a visual representation of that usage over time across your hybrid infrastructure, including physical and virtual technology deployments; on-premise and cloud environments; and cluster, instance, and workload use cases.

From the subscriptions service dashboard, you have an account-level view of current and historical subscription usage, along with the remaining capacity for growth and scaling. You also have a view of the subscriptions that are in use in the account and of the systems or other entities that are using those subscriptions. The account-level view of the subscriptions service dashboard can be shared within an organization among procurement personnel, system administrators, IT administrators, and operators for collaborative management of subscriptions, from purchasing and renewals to deployment decisions.

The subscriptions service and simple content access are designed to work together to simplify and streamline the overall subscription experience. By removing the need to attach subscriptions at the system level, simple content access reduces complexity and saves time when you are adding, removing, and renewing subscriptions. By offering visibility into subscription usage, the subscriptions service eliminates manual subscription management and enables account-wide governance of your subscriptions.

If your organization is not already using the subscriptions service, some steps are required to begin using it.

When you begin deploying subscriptions, it is important for the different personas in your organization to understand how and where those subscriptions are being used. Operations personas, including IT administrators and system administrators, need to build and manage systems to run specific workloads. Procurement personas need to manage purchases by balancing the account’s subscription footprint with current and future business needs.

The setting of use case data on a Red Hat Enterprise Linux (RHEL) system to record its intended use is done through a set of attributes that are collectively known as system purpose.

System purpose attributes include the following types of information:

The following default values are available for each RHEL system purpose attribute:

These system purpose attribute values help operators guide workloads to the correct systems and help procurement personnel filter and analyze system usage in tools such as the subscriptions service to make more informed purchasing decisions.

You can set system purpose values during multiple phases of the system life cycle, enabling your organization to set these values at the most appropriate point in your process. You can set system purpose values at build time, when you are creating installable images for your subscription content, at connection time, during installation and registration tasks, or at runtime, when you begin using the content. For example:

You can use the rhc connect command to register a RHEL 8.8 or later system to Red Hat and enable Red Hat Insights with a single command. Registering a system with the rhc client gives it access to protected content through the Red Hat CDN.

Registering a system to Red Hat requires authentication. There are two authentication methods available:

Activation keys combine all the system registration steps into one secure, automated process. For example, you can use a preconfigured activation key to automatically register and apply the selected features to a RHEL system with a single command. Additionally, you can put an activation key into a Kickstart file to bulk-provision the registration of multiple RHEL systems. If the file is shared by multiple users, the activation key authenticates the processes without exposing username and password values.

# rhc connect --activation-key=<activation_key_name> --organization=<organization_ID>

Connecting kvm-07-guest03.hv2.lab.eng.bos.redhat.com to Red Hat.
This might take a few seconds.

• Connected to Red Hat Subscription Management
• Connected to Red Hat Insights
• Activated the Remote Host Configuration daemon

Successfully connected to Red Hat!

Manage your connected systems: https://red.ht/connector

# rhc connect --username=<username> --password=<password>

# rhc disconnect

Disconnecting <$HOSTNAME> from console.redhat.com.
This might take a few seconds.
Deactivated the Red Hat connector daemon
Manage your Red Hat connector systems: https://red.ht/connector

If you want to register a RHEL 8.7 or earlier system, or access content repositories by using a Satellite Server, then you must use the subscription-manager register command to connect to Red Hat. Optionally, if you want to enable predictive analytics and remediation capabilities, then you can use the insights-client --register command to connect the registered system to Red Hat Insights.

Registering a system to Red Hat requires authentication. There are two authentication methods available for the Subscription Manager client:

Activation keys are created and configured by an RHC administrator in your organization. The organization ID is the numeric identifier for your organization and is separate from your account number. The activation keys and ID for your organization are displayed on the Activation Keys page in the Hybrid Cloud Console.

Activation keys combine all the system registration steps into one secure, automated process. For example, you can use a preconfigured activation key to automatically register and apply the selected features to a RHEL system with a single command. Additionally, you can put an activation key into a Kickstart file to bulk-provision the registration of multiple RHEL systems. If the file is shared by multiple users, the activation key authenticates the processes without exposing username and password values.

# subscription-manager unregister

# Unregistering from: subscription.rhsm.redhat.com:443/subscription
# System has been unregistered

If you want to use a Satellite Server, then you must register your system with the Subscription Manager client.

You must register your host system to a Satellite Server before you can synchronize your Satellite content with the Red Hat Content Delivery Network (CDN).

Anaconda is a customizable RHEL installer. The Anaconda GUI can guide you through most installations, even if you have never installed Linux before. You can use the GUI to register your RHEL system during the installation process.

For more information about using the Anaconda installer GUI to register RHEL, see Additional Resources.

The RHEL web console is a Red Hat Enterprise Linux web-based interface designed for managing and monitoring your local system, as well as Linux servers located in your network environment. You can use the web console GUI to register your system.

Using the web console GUI to register your system to Red Hat requires authentication. There are two authentication methods available:

For more information about registering your system with the RHEL web console, see Additional Resources.

The following web-based registration assistants are available to guide you through the best registration process for your system:

Virtual machines can use host-based subscriptions instead of consuming entitlements from physical subscriptions. A host-based subscription is attached to a hypervisor and entitles it to provide subscriptions to its virtual machines. Many host-based subscriptions provide entitlements for unlimited virtual machines.

To allow virtual machines to inherit subscriptions from their hypervisors, you must install and configure virt-who. Virt-who queries the virtualization platform and reports hypervisor and virtual machine information to Red Hat Subscription Management.

When a virtual machine is registered with auto-attach enabled, and sufficient host-based subscriptions are available, one of the following behaviors occurs:

If auto-attach is enabled, but virt-who is not running or there are no host-based subscriptions available, Subscription Management attaches physical subscriptions to the virtual machines instead, which might consume more entitlements than intended.

If auto-attach is not enabled, virtual machines cannot use host-based subscriptions.

To see if a subscription requires virt-who, log in to to the Customer Portal at https://access.redhat.com, navigate to Subscriptions > Subscription Utilization, and select a subscription. If "Virt-Who: Required" appears in the SKU Details, you must configure virt-who in order to use that subscription.

A virtual machine requests a subscription from Subscription Management.

Subscription Management grants the virtual machine a temporary subscription, valid for a maximum of seven days, while it determines which hypervisor the virtual machine belongs to.

Virt-who connects to the hypervisor or virtualization manager and requests information about its virtual machines.

The hypervisor or virtualization manager returns a list of its virtual machines to virt-who, including each UUID.

Virt-who reports the list of virtual machines and their hypervisors to Subscription Management.

Subscription Management attaches a permanent subscription to the virtual machine, if sufficient entitlements are available.

To allow virtual machines to inherit subscriptions from their hypervisors, complete the following steps:

Virt-who is configured using files that specify details such as the virtualization type and the hypervisor or virtualization manager to query. The supported configuration is different for each virtualization platform.

[hypervisor1]
type=hyperv
server=hypervisor1.example.com
username=virt_who_user
encrypted_password=bd257f93d@482B76e6390cc54aec1a4d
hypervisor_id=hostname
owner=1234567

The type and server values depend on the virtualization platform. The following table provides more detail.

The username refers to a read-only user on Microsoft Hyper-V or VMware vCenter, which you must create before configuring virt-who. Virt-who uses this account to retrieve the list of virtual machines. You do not need a dedicated virt-who user for Red Hat hypervisors.

[global]
interval=3600 1
debug=True 2

[defaults]
owner=1234567 1
hypervisor_id=hostname 2

[system_environment]
http_proxy= https://proxy.example.com:443 1
no_proxy=* 2

Use this procedure to attach a host-based subscription, such as Red Hat Enterprise Linux for Virtual Datacenters, to hypervisors that are already registered.

To register a new hypervisor, see Using and Configuring Red Hat Subscription Manager. You must register a hypervisor before configuring virt-who to query it.

Repeat these steps for each hypervisor.

Repeat these steps for each hypervisor.

Use this procedure to configure a Red Hat Enterprise Linux 7 server to run the virt-who service for VMware vCenter and Microsoft Hyper-V. The server can be physical or virtual.

You do not need a separate virt-who host for Red Hat hypervisors.

The supported virt-who configuration is different for each virtualization platform:

Register virtual machines with auto-attach so that they inherit a subscription from their hypervisor.

Repeat these steps for each virtual machine.

Repeat these steps for each virtual machine.

If the virtual machine has already been reported by virt-who, the virtual machine inherits a subscription from its hypervisor.

If the virtual machine has not been reported by virt who, the virtual machine receives a temporary subscription while Subscription Management waits for virt-who to provide information about which hypervisor the virtual machine is running on. After virt-who provides this information, the virtual machine inherits a subscription from its hypervisor.

# systemctl status virt-who.service

For more detailed logging, enable the debugging option in the /etc/virt-who.conf file:

[global]
debug=True

Restart the virt-who service for the change to take effect.

When the underlying issue is resolved, modify the /etc/virt-who.conf file to disable debugging, then restart the virt-who service.

The expected output of the virt-who --one-shot and virt-who --print commands is a list of hypervisors and their virtual machines, in JSON format. The following is an extract from a VMware vSphere instance. The output from all hypervisors follows the same structure.

{
    "guestId": "422f24ed-71f1-8ddf-de53-86da7900df12",
    "state": 5,
    "attributes": {
        "active": 0,
        "virtWhoType": "esx",
        "hypervisorType": "vmware"
    }
},

The expected output for the virt-who --status command is a plain-text summary of the connection status for each configuration in virt-who.

+-------------------------------------------+
           Configuration Status
+-------------------------------------------+
Configuration Name: esx_config1
Source Status: success
Destination Status: success

Configuration Name: hyperv-55
Source Status: failure
Destination Status: failure

The expected output for the virt-who --status command with the --json option provides additional information about each configuration, including its last successful run, in JSON format. This output also includes details about the success or failure status of each configuration.

"configurations": [
    {
        "name":"esx-conf1",
        "source":{
            "connection":"https://esx_system.example.com",
            "status":"success",
            "last_successful_retrieve":"2020-02-28 07:25:25 UTC",
            "hypervisors":20,
            "guests":37
        },
        "destination":{
            "connection":"candlepin.example.com",
            "status":"success",
            "last_successful_send":"2020-02-28 07:25:27 UTC",
            "last_successful_send_job_status":"FINISHED"
        }
    },
    {
        "name":"hyperv-55",
        "source":{
            "connection":"windows10-3.company.com",
            "status":"failure",
            "message":"Unable to connect to server: invalid credentials",
            "last_successful_retrieve":null
        },
        "destination":{
            "connection":"candlepin.company.com",
            "status":"failure",
            "message":"ConnectionRefusedError: [Errno 111] Connection refused",
            "last_successful_send":null,
            "last_successful_send_job_status":null
        }
    }
]
}

The virt-who --status command can also be used with the --debug and --config options to provide additional information about the configuration files.

Alternatively, you can test an individual file after moving it by using the --config option to specify its location. For example:

# virt-who --debug --one-shot --config /tmp/conf_name.conf

Starting with RHEL 9 Beta, you can enter virt-who --status with the --debug and --config options to identify the configuration file causing the issue without removing any other files from the directory. For example:

#virt-who --debug --status --config /tmp/conf_name.conf

You can also enter the command with the --json option to view more detailed information about each configuration in JSON format. For example:

#virt-who --debug --status --json --config /tmp/conf_name.conf

# systemctl stop virt-who
# virt-who -op >/tmp/virt-who.json
# systemctl start virt-who
# cat /tmp/virt-who.json | json_reformat | grep name | sort | uniq -c | sort -nr | head -n10
  3    "name": "localhost"
  1    "name": "rhel1.example.com"
  1    "name": "rhel2.example.com"
  1    "name": "rhel3.example.com"
  1    "name": "rhel4.example.com"
  1    "name": "rhvh1.example.com"
  1    "name": "rhvh2.example.com"
  1    "name": "rhvh3.example.com"
  1    "name": "rhvh4.example.com"
  1    "name": "rhvh5.example.com"

In this example, three hypervisors have the same FQDN (localhost), and must be corrected to use unique FQDNs.

# systemctl stop virt-who
# virt-who -op >/tmp/virt-who.json
# systemctl start virt-who
# cat /tmp/virt-who.json | json_reformat | grep "guestId" | sort | uniq -c | sort -nr | head -n10

# systemctl stop virt-who
# virt-who -op >/tmp/virt-who.json
# systemctl start virt-who
# cat /tmp/virt-who.json | json_reformat | grep name | sort | uniq -c | wc -l

Starting with RHEL 9 Beta, enter the following command to check the number of hypervisors that virt-who reported during its last successful run cycle:

# virt-who --status --json

# systemctl stop virt-who
# virt-who -op >/tmp/virt-who.json
# systemctl start virt-who
# cat /tmp/virt-who.json | json_reformat | grep "guestId" | sort | uniq -c | wc -l

Starting with RHEL 9 Beta, enter the following command to check the number of guests that virt-who reported during its last successful run cycle:

# virt-who --status --json

You must restart the virt-who service after modifying a configuration file.

[system_environment]
no_proxy=*

You must restart the virt-who service after modifying a configuration file.

Red Hat Subscription Manager tracks the Red Hat products that your organization has purchased and the systems that the products are installed on. Subscription Manager establishes the relationship between the product subscriptions that are available to the system and the elements of infrastrcuture of your business where those subscriptions are allocated.

While Red Hat products are available through a GNU Public License, Red Hat supports its products through a subscription-based license. Support includes:

Red Hat Subscription Management provides administrators with the following information:

Red Hat Subscription Management allows administrators to identify the relationship between their systems and the subscriptions used by those systems from two different perspectives:

Before you can register your system to Red Hat, you need an active subscription. Subscriptions can be purchased through the Red Hat Store or by contacting Sales directly. With a registered system and an active subscription, you can do the following tasks:

Each element in the subscription service must be uniquely identified. This allows true relationships to be established between the system, the products, and the subscriptions. The subscription service generates and installs these certificates on the local system:

Subscription management delivers better information and offers administrators better control over their infrastructures.

All Red Hat Enterprise Linux subscriptions automatically include the following tools for managing the subscription configuration:

The diversity of tools allows administrators to create a workflow that fits both the business and infrastructure demands of their organization.

To manage subscriptions, administrators need to know the following information:

You can view your subscriptions and their details in the following ways:

The following table shows options that you can use to manage your subscriptions with the subscription-manager command.

[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

You use system purpose to record the intended use of a Red Hat Enterprise Linux (RHEL) system. Setting system purpose allows you to specify system attributes, such as the role, service level agreement, and usage. The following values are available for each system purpose attribute by default.

Role

Service Level Agreement

Usage

Configuring system purpose offers the following benefits:

You can set system purpose data in any of the following ways:

[root@localhost ~]# subscription-manager syspurpose role --list

[root@localhost ~]# subscription-manager syspurpose role --list --username=<username> --password=<password> --organization=<organization_ID> --token=<token>

+-------------------------------------------+
               Available role
+-------------------------------------------+
 - Red Hat Enterprise Linux Workstation
 - Red Hat Enterprise Linux Server
 - Red Hat Enterprise Linux Compute Node

# subscription-manager syspurpose addons --list
There are no available values for the system purpose "addons" from the available subscriptions in this organization.

[root@localhost ~]# subscription-manager syspurpose role --set=”foo”

[root@localhost ~]# subscription-manager syspurpose role --set=”foo” --username=<username> --password=<password> --organization=<organization_ID> --token=<token>

Warning: Provided value "foo" is not included in the list of valid values
 - Red Hat Enterprise Linux Workstation
 - Red Hat Enterprise Linux Server
 - Red Hat Enterprise Linux Compute Node
role set to "foo".

If you use a Red Hat Satellite Server, then you can enable simple content access in the following ways:

If you do not use a Satellite Server, then you can enable simple content access through the Red Hat Customer Portal.

After simple content access is enabled, you can complete additional post-enablement steps related to activation key, host group, and host configuration through the Hybrid Cloud Console.

Only users on a disconnected Satellite Server create and manage subscription manifests from the Customer Portal.

Users on a connected Satellite Server create and manage their subscription manifests in the Manifests section of the Red Hat Hybrid Cloud Console. For information about creating and managing subscription manifests for a connected Satellite Server, see Creating and managing a manifest for a connected Satellite Server.

Part of subscription management is tracking updates and new releases of software. Whenever an update is available - from a bug fix to a new release - a notification email can be sent to you. The notifications are only sent for registered systems which have subscriptions for that product associated with them.

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