Getting Started with RHEL System Registration
Abstract
Chapter 1. The value of registering a RHEL system to Red Hat
Registration establishes an authorized connection between your system and Red Hat. Red Hat issues the registered system, whether a physical or virtual machine, a certificate that identifies and authenticates the system so that it can receive protected content, software updates, security patches, support, and managed services from Red Hat.
With a valid subscription, you can register a Red Hat Enterprise Linux (RHEL) system in the following ways:
- During the installation process, using an installer graphical user interface (GUI) or text user interface (TUI)
- After installation, using the command line interface (CLI)
- Automatically, during or after installation, using a Kickstart script or an activation key.
The specific steps to register your system depend on the version of RHEL that you are using and the registration method that you choose.
Registering your system to Red Hat enables features and capabilities that you can use to manage your system and report data. For example, a registered system is authorized to access protected content repositories for subscribed products through the Red Hat Content Delivery Network (CDN) or a Red Hat Satellite Server. These content repositories contain Red Hat software packages and updates that are available only to customers with an active subscription. These packages and updates include security patches, bug fixes, and new features for RHEL and other Red Hat products.
You can use the protected content repositories to manage your system in the following ways:
- Stay up-to-date with the latest security patches and bug fixes for your subscribed products, which helps to ensure that your system is secure and stable.
- Install and update Red Hat software packages and tools, such as Red Hat OpenShift, Red Hat Ansible Automation Platform, and Red Hat Satellite, that are only available to customers with an active subscription.
- Benefit from Red Hat expertise and support, including access to technical resources, documentation, and support services.
You can also connect a registered system to various Red Hat hosted services that manage and report system and subscription data and provide other advanced functions. In addition, you can use the Satellite solution for its robust system and subscription management capabilities and its flexible connectivity options that are more tailored to your operational needs.
Registered systems can connect to the following Red Hat managed services:
Red Hat Subscription Management
Select functions for subscription management that were previously on the Red Hat Customer Portal are now available in the Red Hat Hybrid Cloud Console. These functions include subscription inventory, activation keys, and manifests for a connected Red Hat Satellite Server.
The subscriptions service
A subscription reporting service in the Hybrid Cloud Console that provides a visual representation of the subscription usage across the constituent parts of your hybrid infrastructure, including physical and virtual technology deployments; on-premise and cloud environments; and cluster, instance, and workload use cases for select Red Hat product portfolios.
Red Hat Insights
A managed service in the Hybrid Cloud Console that uses predictive analytics, remediation capabilities, and deep domain expertise to simplify complex operational tasks. These tasks include identifying security and performance risks, tracking licenses, and managing costs.
Red Hat Satellite
A systems management solution to deploy, scale, and manage Red Hat infrastructure across physical, virtual, and cloud environments. Satellite enables users to control the full lifecycle of Red Hat systems, including content management, patching, provisioning, configuration, and subscription management. By automating most tasks related to maintaining systems, Satellite helps organizations increase efficiency, reduce operational costs, and enable IT to better respond to strategic business needs.
Chapter 2. Preparing to register RHEL systems
As you and other members of your Red Hat organization begin purchasing multiple subscriptions, installing software, and registering systems, the tasks required to manage these subscriptions across system deployments in physical, virtual, and cloud environments can become increasingly complex. Red Hat provides additional process and tooling options beyond the system registration tools to help with these tasks.
If your organization is an established Red Hat customer, review your current tooling to ensure that you are taking advantage of the latest subscription experience. If your organization is a new Red Hat customer, some of this tooling is built in as your default subscription experience. Other tooling is optional, but recommended, to help you manage your environment.
- Review information about Red Hat accounts, so that your subscriptions and systems are associated with the correct accounts for your use cases.
- Review information about simple content access, so that you can enable the simplified “register and run” subscription experience that removes the need for complex system-level subscription attachment.
- Review information about the subscriptions service, so that you can use that service to gain an account-level view of current and historical subscription usage.
- Review information about system purpose attributes and values, so that you can match your subscriptions with use case information that enriches subscriptions service data and helps you understand subscription utilization across your account.
2.1. Your Red Hat account
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:
- A corporate account that enables a set of users, such as system administrators, purchasing agents, IT management, and so on, to centrally purchase subscriptions and administer systems within a corporation or within a corporate organizational structure such as a function or division.
- A personal account that is for a single user to purchase their own subscriptions and administer their own systems.
If you meet any of the following criteria, you already have a Red Hat account:
- You are part of a Red Hat corporate account and organization for your company, and an Organization Administrator has already created a Red Hat account for you within that organization.
- You have previously purchased a Red Hat subscription.
- You have already visited the Hybrid Cloud Console web page or other Red Hat web pages to create an 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.
Additional resources
- For more information about the status of any Red Hat accounts that you own, contact Red Hat customer service.
- For more information about Red Hat accounts, see the "How to Create a New Red Hat Login ID and Account" Customer Portal article.
2.2. Simple content access enablement
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.
The entitlement-based subscription model is no longer the default subscription mode, is currently deprecated, and will be retired in the future. Red Hat accounts that are still using the entitlement-based subscription model should begin working with their Red Hat account team, such as a technical account manager (TAM) or solution architect (SA), to answer questions or prepare for migration to simple content access.
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.
- If your organization uses the subscription management capabilities of Red Hat Subscription Management to manage your systems and subscriptions, an Organization Administrator for your Red Hat account can enable simple content access from Red Hat Subscription Management in the Red Hat Customer Portal. As of 15 July 2022, simple content access is enabled by default for all new Red Hat accounts.
- If your organization uses Red Hat Satellite version 6.12 or earlier, a Satellite administrator can enable simple content access from the manifests management tool that is available in Red Hat Hybrid Cloud Console. The manifest can then be used to apply simple content access at the Satellite organization level. For newly created manifests, simple content access is enabled by default.
- If your organization uses Red Hat Satellite version 6.13, a Satellite administrator can enable simple content access in the web user interface for Satellite. For newly created Satellite organizations, simple content access is enabled by default. Although currently you can still change the setting of the applied manifest in the Hybrid Cloud Console, the setting on the Satellite organization always overrides the setting on the manifest.
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.
Additional resources
- To learn more about simple content access, see the Getting Started with Simple Content Access guide.
- For information about how to enable simple content access, see Activating simple content access.
- For additional technical information about simple content access, including a deep-dive before-and-after comparison of the subscription workflow and links to instructional videos, see the "Simple Content Access" Customer Portal article.
2.3. Subscriptions service enablement
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.
Activating the subscriptions service
You must activate the subscriptions service for the organization so that the service can begin collecting and displaying data. Activation can be either manual or automated if certain types of subscription purchases are made. If the subscriptions service is not active, any user in the organization can activate it. After activation, it can take up to 24 hours for certain types of data to begin appearing in the subscriptions service.
Setting up the data collection tools
The subscriptions service relies on data that is collected from several other tools that act as data sources. To report Red Hat Enterprise Linux usage, the subscriptions service can use data from the subscription management tools of Red Hat Subscription Management, from Red Hat Satellite, and from Red Hat Insights. You can use one or all of these tools for data collection, according to needs of your IT environment. In addition, data collection related to host-guest mappings requires data from the virt-who tool and the Satellite inventory upload plugin.
Additional resources
- To learn more about the subscriptions service, see the Getting Started with the Subscriptions Service guide.
- For more information about activating the subscriptions service, see Activating and opening the subscriptions service.
- For more information about which data collection tools you should use, see How to select the right data collection tool.
- For more information about configuring the data collection tools, see Setting up the subscriptions service for data collection.
- For additional technical information about the subscriptions service, including an analysis of sample subscriptions service data and and links to instructional videos, see the "Subscription Watch" Customer Portal article.
2.4. System purpose configuration
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 might be known by a different name in other Red Hat products. Collectively, they can also be known as subscription attributes.
System purpose attributes include the following types of information:
- Technical use case information, such as workload information
- Business use case information, such as the IT environment, which determines the scope of support needed for that environment
- Operational use case information, such as the service level
The following default values are available for each RHEL system purpose attribute:
Role (technical use case)
- Red Hat Enterprise Linux Server
- Red Hat Enterprise Linux Workstation
- Red Hat Enterprise Linux Compute Node
Usage (business use case)
- Production
- Development/Test
- Disaster Recovery
Service Level Agreement (operational use case)
- Premium
- Standard
- Self-Support
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:
- During activation key creation
- During image creation by configuring an image builder image with an embedded activation key that has includes system purpose values
- During a GUI installation when using the Connect to Red Hat options to register your system
-
During a Kickstart installation when using the
syspurpose Kickstart
command -
After installation using the
subscription-manager
command-line interface tool
Additional resources
- To configure system purpose with an activation key, see Creating an activation key.
- To configure system purpose for RHEL 9 with Subscription Manager, see Configuring System Purpose using the subscription-manager command-line tool in Performing a standard RHEL 9 installation.
- To configure system purpose for RHEL with Kickstart, see Configuring System Purpose in a Kickstart file in Performing an advanced RHEL 9 installation.
- To configure system purpose for RHEL with Subscription Manager, see Configuring System Purpose in Performing an advanced RHEL 8 installation.
- To configure system purpose for RHEL with Kickstart, see Configuring System Purpose in a Kickstart file in Performing an advanced RHEL 8 installation.
Chapter 3. Registering a RHEL system with command line tools
With root privileges, you can register your Red Hat Enterprise Linux (RHEL) system from the command line interface (CLI). Registration tools for the CLI include the following clients:
rhc client
Registers a RHEL 8.8 or later system to Red Hat and enables Red Hat Insights with a single command. You can use the
rhc connect
command to connect your system to content repositories through the Red Hat CDN.
Subscription Manager client
Registers a RHEL 8.7 or earlier system, or a Satellite-supported system, to Red Hat. You can use the
subscription-manager register
command to connect your system to content repositories through the Red Hat CDN or through a Satellite Server.
Insights client
Enables Red Hat Insights on a system that has been registered with the Subscription Manager client. If you used the
subscription-manager register
command to register your system, then you can use theinsights-client --register
command to enable Insights.
Each registration command requires authentication options. There are two authentication methods available for the rhc and Subscription Manager clients:
- An activation key and organization ID combination
- A username and password combination
The insights-client --register
command uses the same identity certificate that subscription-manager register
uses; therefore, you do not need to authenticate the insights-client --register
command if you have already used an authentication token to register the system with the subscription-manager register
command.
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. Your organization’s activation keys and organization ID are displayed on the Activation Keys page in the Hybrid Cloud Console.
3.1. Registering RHEL 8.8 or later with rhc
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:
- An activation key and organization ID combination
- A username and password combination.
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.
3.1.1. Using an activation key to register RHEL 8.8 or later with rhc
You can use an activation key and a numeric organization identifier (organization ID) with the rhc connect
command to register a system to Red Hat and enable Red Hat Insights with a single command. If an RHC administrator has preconfigured the activation key to apply selected system-level features, such as system purpose attributes, then those features are automatically applied to the system during the registration process.
The activation keys and ID for your organization are displayed on the Activation Key page in the Hybrid Cloud Console.
Prerequisites
- You have a product subscription for RHEL 8.8 or later.
- You are logged in to the Red Hat Hybrid Cloud Console.
- You are logged in as the root user.
- You have the numeric identifier for your organization (organization ID).
Procedure
To use an activation key to register a system with the rhc client, complete the following step:
-
From the terminal, enter the following command, where
<activation_key_name>
is the name of the activation key that you want to use and<organization_ID>
is your organization ID:
# rhc connect --activation-key=<activation_key_name> --organization=<organization_ID>
The expected output confirms that your system is registered. For example:
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
Verification
To confirm that the system was successfully registered, you can view it in the system Inventory on the Hybrid Cloud Console.
Additional resources
- For information about how to register your system with remote host configuration, see link:https://access.redhat.com/articles/rhc-registration [Registering your host using the remote host configuration client].
- For information about how to create and manage activation keys, see Getting started with activation keys on the Hybrid Cloud Console.
3.1.2. Using a username and password to register RHEL 8.8 or later with the rhc client
If you do not have an activation key, you can use a username and password combination with the rhc connect
command to authenticate the registration process of your RHEL 8.8 or later system.
To avoid exposing username and password values in a shared file, use an activation key and organization ID combination to authenticate the registration process.
Prerequisite
- You have an active product subscription for RHEL 8.8 or later.
- You are logged in to the Red Hat Hybrid Cloud Console.
- You are logged in as the root user.
Procedure
To use a username and password combination to register your RHEL system to Red Hat using the rhc client, complete the following step:
- From the terminal, enter the following command:
# rhc connect --username=<username> --password=<password>
Verification
To confirm that the system was successfully registered, view it in the system Inventory on the Hybrid Cloud Console.
3.1.3. Unregistering RHEL 8.8 or later with rhc
Unregistering a system when you no longer want to use RHEL on that system is recommended as a system hygiene best practice. An unregistered system can no longer receive protected content, software updates, security patches, support, or managed services from Red Hat.
Users with root privileges can use the disconnect
command with the rhc client to remove a system from the subscription management services and Red Hat Insights.
Procedure
To disconnect your system, complete the following step:
- From the terminal, enter the following command:
# rhc disconnect
The expected output is similar to the following example:
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
Next steps
After you unregister a system, the system is deleted from the Red Hat hosted services that manage and report system and subscription data. However, due to different internal processes, the system is deleted from these services at different times. For some of these services, you can manage the timing of the deletion.
- For the subscriptions service, the deletion will occur within approximately 24 hours. The timing is determined by the time of day that the subscriptions service does its data snapshot.
- For the Insights for Red Hat Enterprise Linux inventory service, if you take no action the deletion will occur according to the inventory staleness and deletion policy. However, you can manage the timing of deletion. For immediate deletion, you can delete the system manually from the Systems page. You can also change the settings for automatic deletion by editing the policy for staleness and deletion. For more information, see Viewing and managing system inventory.
Additional resources
- For information about how to unregister your system with the rhc client, see Disconnecting a system using remote host configuration.
3.2. Registering RHEL 8.7 or earlier with Subscription Manager
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:
- An activation key and organization ID combination
- A username and password combination
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.
ADDITIONAL RESOURCES
- For information about the organization ID, see Understanding the Red Hat Subscription Management Organization ID.
- For information about how to create and manage activation keys, see Getting started with activation keys on the Hybrid Cloud Console.
3.2.1. Using an activation key to register RHEL 8.7 or earlier with Subscription Manager
You can use an activation key and a numeric organization identifier (organization ID) with the subscription-manager register
command to register a system to Red Hat. If an RHC administrator has preconfigured the activation key to apply the selected system-level features, such as system purpose attributes, then those features are automatically applied to the system during the registration process.
The activation keys and ID for your organization are displayed on the Activation Keys page in the Hybrid Cloud Console.
Prerequisites
- You have a product subscription for RHEL 8.7 or earlier or you have a Satellite Server.
- You are logged in to the Hybrid Cloud Console.
- You are logged in as the root user.
- You have the numeric identifier for your organization (organization ID).
Procedure
To use an activation key to register a system with Subscription Manager, complete the following steps:
From the terminal, enter the following command, where <activation_key_name> is the name of the activation key that you want to use and <organization_ID> is your organization ID:
# subscription-manager register --activation-key=<activation_key_name> --organization=<organization_ID>
The expected output confirms that your system is registered. For example:
The system has been registered with id: 62edc0f8-855b-4184-b1b8-72a9dc793b96
(Optional) From the terminal, enter the following command to connect the registered system to Red Hat Insights:
yum install insights-client insights-client --register
NoteThe
insights-client --register
command uses the same identity certificate thatsubscription-manager register
uses; therefore, you do not need to authenticate theinsights-client --register
command if you have already used an authentication token to register with thesubscription-manager register
command.
Verification
To confirm that the system was successfully registered, you can view it in the system Inventory on the Hybrid Cloud Console.
Additional resources
- For information about how to create and manage activation keys, see Using activation keys.
3.2.2. Using a username and password to register RHEL 8.7 or earlier with Subscription Manager
If you do not have an activation key, you can use a username and password combination with the subscription-manager register
command to register a system to Red Hat.
To avoid exposing username and password values in a shared file, use an activation key and organization ID combination to authenticate the registration process.
Prerequisite
- You have an active product subscription for RHEL 8.7 or earlier.
- You are logged in to the Hybrid Cloud Console.
- You are logged in as the root user.
Procedure
To use a username and password combination to register your RHEL system to Red Hat with the Subscription Manager client, complete the following steps:
From the terminal, enter the following command:
# subscription-manager register --username=<username> --password=<password>
The expected output is similar to the following example:
The system has been registered with ID: 541084ff2-44cab-4eb1-9fa1-7683431bcf
(Optional) From the terminal, enter the following command to connect the registered system to Red Hat Insights:
yum install insights-client insights-client --register
NoteThe
insights-client --register
command uses the same identity certificate thatsubscription-manager register
uses; therefore, you do not need to authenticate theinsights-client register
command if you have already used an authentication token to register with thesubscription-manager register
command.
Verification
To confirm that the system was successfully registered, you can view it in the system Inventory on the Hybrid Cloud Console.
Additional resources
- For assistance with using a username and password to register RHEL with the Subscription Manager client, see the RHEL registration assistant on the Customer Portal.
- For assistance with registering your RHEL system to Red Hat Insights, see the Insights registration assistant on the Hybrid Cloud Console.
3.2.3. Unregistering 8.7 or earlier with Subscription Manager
Unregistering a system when you no longer want to use RHEL on that system is recommended as a system hygiene best practice. An unregistered system can no longer receive protected content, software updates, security patches, support, or managed services from Red Hat.
Users with root privileges can use the unregister
command with the subscription-manager
client to remove a system from the subscription management services. The command also removes any subscriptions and locally deletes the identity and subscription certificates from the system.
Unregistering a system with the subscription-manager
client terminates your access to the protected content available through the Red Hat CDN or Satellite.
Procedure
To unregister your system, complete the following step:
- From the terminal, enter the following command:
# subscription-manager unregister
The expected output is similar to the following example:
# Unregistering from: subscription.rhsm.redhat.com:443/subscription # System has been unregistered
Next steps
After you unregister a system, the system is deleted from the Red Hat hosted services that manage and report system and subscription data. However, due to different internal processes, the system is deleted from these services at different times. For some of these services, you can manage the timing of the deletion.
- For the subscriptions service, the deletion will occur within approximately 24 hours. The timing is determined by the time of day that the subscriptions service does its data snapshot.
- For the Insights for Red Hat Enterprise Linux inventory service, if you take no action the deletion will occur according to the inventory staleness and deletion policy. However, you can manage the timing of deletion. For immediate deletion, you can delete the system manually from the Systems page. You can also change the settings for automatic deletion by editing the policy for staleness and deletion. For more information, see Viewing and managing system inventory.
3.3. Registering Satellite-supported RHEL with Subscription Manager
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).
Chapter 4. Registering a RHEL system with a graphical user interface
Users who prefer a web experience, or who want to register their system during installation, can use a graphical user interface (GUI) to complete the registration process. Registration GUIs are available in the Anaconda Red Hat Enterprise Linux (RHEL) installer, in the RHEL web console, and in the Red Hat Hybrid Cloud Console.
There are also web-based registration assistants available to guide you through the best registration process for your system.
Additional resources
- For assistance with registering RHEL with Subscription Manager, see the RHEL registration assistant on the Customer Portal.
- For assistance with registering your RHEL system to Red Hat Insights, see the Insights registration assistant on the Hybrid Cloud Console.
- For information about registering your RHEL 9 system with the Anaconda installer, see Registering RHEL 9 using the installer GUI.
- For information about using an activation key to register your RHEL 9 system with the web console GUI, see Registering subscriptions with credentials in the web console.
- For information about using an activation key to register your RHEL 8 system with the web console GUI, see Registering subscriptions with activation keys in the web console.
4.1. Registering RHEL with the Anaconda installer
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.
Additional resources
- For information about registering your RHEL 9 system with the Anaconda installer, see Registering RHEL 9 using the installer GUI.
4.2. Registering RHEL with the web console
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:
- An activation key and organization ID combination
- A username and password combination
For more information about registering your system with the RHEL web console, see Additional Resources.
Additional resources
- For information about registering your RHEL 9 system with the web console GUI, see Registering subscriptions with credentials in the web console.
4.3. Registering RHEL with a registration assistant
The following web-based registration assistants are available to guide you through the best registration process for your system:
- Connects a RHEL 8.7 or earlier system to Red Hat
- Connects a Satellite-supported system to Red Hat
- Supports the use of a username and password for authentication
Insights registration assistant
- Connects a RHEL 8.8 or later system to Red Hat Insights
- Supports the use of an activation key for authentication
4.3.1. Registering to Insights with the Insights registration assistant
The Insights registration assistant on the Hybrid Cloud Console can help you register your system to Red Hat Insights. The registration assistant offers a customized registration workflow based on your environment.
Procedure
To use the Insights registration assistant to connect your system to Red Hat Insights, complete the following steps:
From the Red Hat Insights navigation menu, click Register Systems to open the registration page.
NoteThe Insights registration assistant guides you through the setup process for the Red Hat Insights client.
Select system-level features to tailor the setup instructions for your environment.
NoteDepending on your environment, some instructions include registration commands that an authorized user can copy and paste into the terminal.
Additional resources
- For assistance with using a username and password to register RHEL with the Subscription Manager client, see the RHEL registration assistant on the Customer Portal.
4.3.2. Registering to Red Hat with the RHEL registration assistant
The RHEL registration assistant on the Customer Portal can help you register your system to Red Hat using a username and password.
To avoid exposing username and password values in a shared file, use an activation key and organization ID combination to authenticate the registration process.
Additional resources
- For assistance with using a username and password to register RHEL with the Subscription Manager client, see the RHEL registration assistant on the Customer Portal.
Chapter 5. Automating RHEL system registration with a Kickstart file
You can use a Kickstart file with a system installer and an activation key to automatically register a system during the installation process. This is especially useful if you want to install and register multiple instances of RHEL. You can also use a single Kickstart file to install RHEL on multiple computers.
You can put an activation key into a shared Kickstart file to authenticate the processes without exposing username and password values. Additionally, administrators can preconfigure the activation key with selected system-level features, such as system purpose attributes. When an authorized user uses the activation key to authenticate the registration process, the selected features are automatically applied to the system with a single command.
Additional resources
- For information about registering your RHEL 9 system with Kickstart, see Registering and installing RHEL from the Content Delivery Network and Satellite.
- For information about registering your RHEL 8 system with Kickstart, see Registering and installing RHEL from the CDN using Kickstart.
- For information about registering your RHEL 7 system with Kickstart, see Automatic Installation.
Chapter 6. Configuring virtual machine subscriptions
You can use host-based subscriptions for Red Hat Enterprise Linux virtual machines in the following virtualization platforms:
- Red Hat Virtualization
- Red Hat Enterprise Linux Virtualization (KVM) (KVM)
- Red Hat OpenStack Platform
- VMware vSphere
- (HyperVBrandName)
- OpenShift Virtualization
6.1. Host-based subscriptions
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 the virt-who daemon. 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 the virtual machine has been reported by virt-who and a host-based subscription is attached to the hypervisor, the virtual machine inherits a subscription from the hypervisor.
- If the virtual machine has been reported by virt-who, and the hypervisor is registered to Subscription Management but does not have a host-based subscription attached, a host-based subscription is attached to the hypervisor and inherited by the virtual machine.
- If the virtual machine, or its hypervisor, has not been reported by virt-who, Subscription Management grants the virtual machine a temporary subscription, valid for up to seven days. After virt-who reports updated information, Subscription Management can determine which hypervisor the virtual machine is running on and attach a permanent subscription to the virtual machine.
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.
System Purpose add-ons have no effect on the auto-attach feature in Red Hat Enterprise Linux 8.0, 8.1, and 8.2.
If you are managing subscriptions in entitlement-based mode, you can use the Customer Portal to check if a subscription requires the virt-who daemon to be enabled. To check if a subscription requires virt-who, log in to the Customer Portal at https://access.redhat.com, navigate to Subscriptions, and select a subscription to view the details. If "Virt-Who: Required" appears in the SKU Details, you must configure virt-who to use that subscription.
If you are managing subscriptions with Red Hat Satellite, you can use the Satellite web UI to check if a subscription requires the virt-who daemon to be enabled. To check if a subscription requires virt-who, open the Satellite web UI and navigate to Content > Subscriptions. If the Requires Virt-Who column shows a checkmark for a subscription, you must configure virt-who to use that subscription.
Virtual machine subscription process
This diagram shows the subscription workflow when a virtual machine has not yet been reported by virt-who:
![Virtual Machine Subscription Process](https://access.redhat.com/webassets/avalon/d/Subscription_Central-1-latest-Getting_Started_with_RHEL_System_Registration-en-US/images/0c78c4db9f365b3949b22ac12a42f154/80_RHSM_Config_VMs_0420.png)
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.
Additional resources
For more information about the Red Hat subscription model, see Introduction to Red Hat Subscription Management Workflows.
To allow virtual machines to inherit subscriptions from their hypervisors, complete the following steps:
Prerequisites
- Ensure you have active subscriptipns for all of the hypervisors that you plan to use.
- For Microsoft Hyper-V, create a read-only virt-who user with a non-expiring password on each hypervisor that runs Red Hat Enterprise Linux virtual machines.
- For VMware vSphere, create a read-only virt-who user with a non-expiring password on the vCenter Server. The virt-who user requires at least read-only access to all objects in the vCenter Data Center.
- For OpenShift Virtualization, create a Service Account and grant it with an admin role in the OpenShift cluster master, virt-who need the Service Account Token to connect the OpenShift cluster.
6.2. Virt-who configuration for each virtualization platform
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.
-
Individual configuration files are stored in the
/etc/virt-who.d/
directory. You must create an individual configuration file for each hypervisor or virtualization manager.
Example virt-who configuration file
This example shows an individual virt-who configuration file for a Microsoft Hyper-V hypervisor:
[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.
Required configuration for each virtualization platform
Use this table to plan your virt-who configuration:
Supported virtualization platform | Type specified in the configuration file | Server specified in the configuration file | Server where virt-who is installed |
---|---|---|---|
Red Hat Virtualization Red Hat Enterprise Linux Virtualization (KVM) (KVM) Red Hat OpenStack Platform | libvirt | Not required | Each hypervisor |
VMware vSphere | esx | vCenter Server | A dedicated RHEL server |
Microsoft Hyper-V | hyperv | Hypervisor | A dedicated RHEL server |
OpenShift Virtualization | kubevirt | OpenShiftCluster Master | A dedicated Red Hat Enterprise Linux server |
The rhevm
and xen
hypervisor types are not supported.
6.2.1. Virt-who general configuration
'/etc/sysconfig/virt-who' will not be supported in the next major release, the global configuration file will be replaced by '/etc/virt-who.conf'. (i.e. 'VIRTWHO_DEBUG', 'VIRTWHO_ONE_SHOT', 'VIRTWHO_INTERVAL', 'HTTPS_PROXY, NO_PROXY').
The general configuration file (located at '/etc/virt-who.conf') is created automatically when you install virt-who. You can use the default values or edit this file if required. It has three special sections: '[global]', '[defaults]', and '[system_environment]'.
The settings in the global section affect the overall operation of the application.
Example: Global section
[global] interval=3600 1 debug=True 2
- 1
- How often to check connected hypervisors for changes (seconds). Also affects how often a mapping is reported. Because the virtual machines are granted temporary subscriptions for up to seven days, frequent queries are not required; you can select an interval that suits the size of your environment.
- 2
- Enable debugging output
The settings in the defaults that can be are applied as defaults to the configurations found in ''/etc/virt-who.d/.conf'. If you enable the options in this section, you don’t need to set them in ''/etc/virt-who.d/.conf' again.
Example: Defaults section
[defaults] owner=1234567 1 hypervisor_id=hostname 2
The settings in the system_environment are written to the system’s environment and are available for the duration of the process execution, it will be used whether virt-who was started as a service or from the command line.
Example: system_environment section
[system_environment] http_proxy= https://proxy.example.com:443 1 no_proxy=* 2
The section [system_environment] is supported from virt-who-0.30.x-1.el8 (RHEL 8.4). If you are using the old virt-who version, please set 'HTTP_PROXY', 'NO_PROXY' by '/etc/sysconfig/virt-who'.
6.3. Attaching a host-based subscription to hypervisors
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.
Prerequisites
- You have active subscriptions for all of the hypervisors that you plan to use.
Web UI procedure
- Log in to the Customer Portal at https://access.redhat.com.
- Navigate to Subscriptions > Systems and click the name of the hypervisor.
- Click the Subscriptions tab.
- Click Attach Subscriptions.
- Select the host-based subscription, then click Attach Subscriptions.
Repeat these steps for each hypervisor.
CLI procedure
On the hypervisor, identify and make a note of your host-based subscription’s Pool ID:
# subscription-manager list --all --available --matches 'Host-based Subscription Name'
Attach the host-based subscription to the hypervisor:
# subscription-manager attach --pool=Pool_ID
Verify that the host-based subscription is attached:
# subscription-manager list --consumed
Repeat these steps for each hypervisor.
6.4. Preparing a virt-who host
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.
Procedure
- Install a Red Hat Enterprise Linux 7 server. Only a CLI environment is required. For more information, see the Red Hat Enterprise Linux 7 Installation Guide.
Register the server:
# subscription-manager register --auto-attach
Open a network port for communication between virt-who and the subscription service:
# firewall-cmd --add-port="443/tcp" # firewall-cmd --add-port="443/tcp" --permanent
Open a network port for communication between virt-who and each hypervisor or virtualization manager:
- VMware vCenter: TCP port 443
- Microsoft Hyper-V: TCP port 5985
Install virt-who:
# yum install virt-who
Optional: Edit the
/etc/virt-who.conf
file to change or add global settings. These settings apply to all virt-who connections from this server.-
Change the value of
VIRTWHO_INTERVAL
to specify how often, in minutes, virt-who queries the virtualization platform. Because the virtual machines are granted temporary subscriptions for up to seven days, frequent queries are not required; you can select an interval that suits the size of your environment. Once a day (1440
) is suitable for most environments. If you want to use an HTTP proxy for virt-who communication, add a line specifying the proxy:
http_proxy=https://proxy.example.com:443
If you do not want to use an HTTP proxy for any virt-who communication from this server, add the following line:
NO_PROXY=*
-
Change the value of
Start and enable the virt-who service:
# systemctl enable --now virt-who
6.5. Configuring virt-who
The use of environment variables and the use of the sysconfig file to configure virt-who are deprecated. Their use will be ignored in the next major release.
The supported virt-who configuration is different for each virtualization platform:
- To configure virt-who for Red Hat products, see Installing and configuring virt-who on Red Hat hypervisors.
- To configure virt-who for VMware vCenter, see Configuring virt-who to connect to VMware vCenter.
- To configure virt-who for Microsoft Hyper-V, see Configuring virt-who to connect to Microsoft-Hyper-V.
- To configure virt-who for OpenShift Virtualization, see Configuring virt-who to connect to OpenShift Virtualization.
6.5.1. Installing and configuring virt-who on Red Hat hypervisors
Use this procedure to install and configure virt-who on each hypervisor in Red Hat Enterprise Linux Virtualization (KVM) (KVM), Red Hat Virtualization, or Red Hat OpenStack Platform.
Prerequisites
- Register the hypervisor to Red Hat Subscription Management.
-
If you are using Red Hat Virtualization Host (RHVH), update it to the latest version so that the minimum virt-who version is available. Virt-who is available by default on RHVH, but cannot be updated individually from the
rhel-7-server-rhvh-4-rpms
repository.
Procedure
Install virt-who on the hypervisor:
# yum install virt-who
Optional: Edit the
/etc/virt-who.conf
file to change or add global settings. Because virt-who is installed locally, these settings apply only to this hypervisor.-
Change the value of
VIRTWHO_INTERVAL
to specify how often, in minutes, virt-who queries the hypervisor. Because the virtual machines are granted temporary subscriptions for up to seven days, frequent queries are not required; you can select an interval that suits the size of your environment. Once a day (1440
) is suitable for most environments. If you want to use an HTTP proxy for virt-who communication, add a line specifying the proxy:
http_proxy=https://proxy.example.com:443
If you do not want to use an HTTP proxy for any virt-who communication from this server, add the following line:
NO_PROXY=*
NoteNO_PROXY=*
can be used but only in/etc/sysconfig/virt-who
.NO_PROXY
is not a valid configuration in/etc/virt-who.conf
.
-
Change the value of
Copy the template configuration file to a new individual configuration file:
# cp /etc/virt-who.d/template.conf /etc/virt-who.d/local.conf
Edit the configuration file you just created, changing the example values to those specific to your configuration:
[local] 1 type=libvirt 2 owner=1234567 3 hypervisor_id=hostname 4
- 1
- The name does not need to be unique, because this configuration file is the only one managed by this instance of virt-who.
- 2
- Specifies that this virt-who connection is to a Red Hat hypervisor.
- 3
- The organization the hypervisor belongs to. You can find the organization by running
subscription-manager orgs
on the hypervisor. - 4
- Specifies how to identify the hypervisor. Use
hostname
to provide meaningful host names to Subscription Management. Alternatively, you can useuuid
to avoid duplication if a hypervisor is renamed. Do not usehwuuid
for an individual hypervisor.
Start and enable the virt-who service:
# systemctl enable --now virt-who
Repeat these steps for each hypervisor.
6.5.2. Configuring virt-who to connect to VMware vCenter
Use this procedure to configure virt-who to connect to a VMware vCenter Server.
Prerequisites
- Create a read-only virt-who user on the vCenter Server. The virt-who user requires at least read-only access to all objects in the vCenter Data Center.
- Prepare a virt-who host on a Red Hat Enterprise Linux server.
Procedure
On the virt-who host, encrypt the virt-who user’s password with the
virt-who-password
utility:# virt-who-password
When prompted, enter the password of the virt-who user, then make a note of the encrypted form of the password.
Copy the template configuration file to a new individual configuration file:
# cp /etc/virt-who.d/template.conf /etc/virt-who.d/vcenter1.conf
To make it easy to identify the configuration file when troubleshooting, use the VMware vCenter host name as the new file’s name. In this example, the host name is vcenter1.
Edit the configuration file you just created, changing the example values with those specific to your configuration:
[vcenter1] 1 type=esx 2 server=vcenter1.example.com 3 username=virt_who_user 4 encrypted_password=bd257f93d@482B76e6390cc54aec1a4d 5 owner=1234567 6 hypervisor_id=hostname 7 filter_hosts=esx1.example.com, esx2.example.com 8
- 1
- The name must be unique for each individual configuration file. Use the vCenter Server host name to make it easy to identify the configuration file for each hypervisor.
- 2
- Specifies that this virt-who connection is to a VMware vCenter Server.
- 3
- The FQDN of the vCenter Server.
- 4
- The name of the virt-who user on the vCenter Server.
- 5
- The encrypted password of the virt-who user.
- 6
- The organization the hypervisors belong to. You can find the organization by running
subscription-manager orgs
on a hypervisor. - 7
- Specifies how to identify the hypervisors. Use
hostname
to provide meaningful host names to Subscription Management. Alternatively, you can useuuid
orhwuuid
to avoid duplication if a hypervisor is renamed. - 8
- If some hypervisors never run Red Hat Enterprise Linux virtual machines, those hypervisors do not need to be reported by virt-who. You can filter hypervisors using one of the following options. Wildcards and regular expressions are supported. If a name contains special characters, enclose it in quotation marks.
-
filter_hosts
orexclude_hosts
: Provide a comma-separated list of hypervisors according to the specifiedhypervisor_id
. For example, if hypervisors are identified by their host name, they must be included or excluded by their host name. -
filter_host_parents
orexclude_host_parents
: Provide a comma-separated list of clusters. Hypervisors in a filtered cluster are reported by virt-who. Hypervisors in an excluded cluster are not reported by virt-who.
-
Restart the virt-who service:
# systemctl restart virt-who
Repeat these steps for each vCenter Server.
6.5.3. Configuring virt-who to connect to Microsoft Hyper-V
Use this procedure to configure virt-who to connect to a Microsoft Hyper-V hypervisor.
Prerequisites
- Red Hat Enterprise Linux 9 or later.
- Prepare a virt-who host on a Red Hat Enterprise Linux server.
- Enable basic authentication mode for the hypervisor.
- Enable remote management on the hypervisor.
- Create a read-only virt-who user on the hypervisor.
Procedure
On the virt-who host, encrypt the password of the hypervisor’s virt-who user with the
virt-who-password
utility:# virt-who-password
When prompted, enter the password of the virt-who user, then make a note of the encrypted form of the password.
Copy the template configuration file to a new individual configuration file:
# cp /etc/virt-who.d/template.conf /etc/virt-who.d/hyperv1.conf
To make it easy to identify the configuration file when troubleshooting, use the hypervisor’s host name as the new file’s name. In this example, the host name is hyperv1.
Edit the configuration file you just created, changing the example values with those specific to your configuration:
[hyperv1] 1 type=hyperv 2 server=hyperv1.example.com 3 username=virt_who_user 4 encrypted_password=bd257f93d@482B76e6390cc54aec1a4d 5 owner=1234567 6 hypervisor_id=hostname 7
- 1
- The name must be unique for each individual configuration file. Use the hypervisor’s host name to make it easy to identify the configuration file for each hypervisor.
- 2
- Specifies that this virt-who connection is to a Microsoft Hyper-V hypervisor.
- 3
- The FQDN of the Hyper-V hypervisor.
- 4
- The name of the virt-who user on the hypervisor.
- 5
- The encrypted password of the virt-who user.
- 6
- The organization this hypervisor belongs to. You can find the organization by running
subscription-manager orgs
on the hypervisor. - 7
- Specifies how to identify the hypervisor. Use
hostname
to provide meaningful host names to Subscription Management. Alternatively, you can useuuid
to avoid duplication if a hypervisor is renamed. Do not usehwuuid
for an individual hypervisor.
Restart the virt-who service:
# systemctl restart virt-who
Repeat these steps for each hypervisor.
6.5.4. Configuring virt-who to connect to OpenShift Virtualization
Supported Platforms
OpenShift Virtualization supported status by virt-who:
- virt-who-0.28.x-1.el7 (RHEL 7.9)
- virt-who-0.29.x-1.el8 (RHEL 8.3)
Procedure
In the cluster you want to subscribe, create a project and a service account named virt-who:
$ oc new-project virt-who $ oc create serviceaccount virt-who
Create cluster roles to list nodes and virtual machine Instances.
$ oc create clusterrole lsnodes --verb=list --resource=nodes $ oc create clusterrole lsvmis --verb=list --resource=vmis
Create cluster role bindings.
$ oc adm policy add-cluster-role-to-user lsnodes system:serviceaccount:virt-who:virt-who $ oc adm policy add-cluster-role-to-user lsvmis system:serviceaccount:virt-who:virt-who
Verify that the virt-who system account has the permissions to list all running VMs:
$ oc get vmis -A --as=system:serviceaccount:virt-who:virt-who
Install virt-who on a host, which can be a VM running on OpenShift Virtualization itself:
[virtwho-host]$ yum install virt-who
Find your owner number on a subscribed host:
$ subscription-manager orgs
Copy the template configuration file to a new individual configuration file. To make it easy to identify the configuration file when troubleshooting, use the hostname of the cluster API. In this example, the host name is
openshift-cluster-1
.[virtwho-host]# cp /etc/virt-who.d/template.conf /etc/virt-who.d/openshift-cluster-1.conf [cnv] type=kubevirt kubeconfig=/root/.kube/config hypervisor_id=hostname owner=<owner_number>
Get the token of the virt-who service account:
# oc serviceaccounts get-token virt-who
If
/usr/bin/oc
is not available, install/usr/bin/oc
and use the token to log in and to create a valid kubeconfig file. You must specify the cluster api by including the url. For example:[virtwho-host]# oc login https://api.testcluster-1.example.org:6443 --token=<token>
To use the OpenShift Virtualization certificate-authority (CA) certificate in the kubeconfig file, extract it from the cluster and save it to a file on the system running virt-who as the controller daemon:
oc get secret -n openshift-kube-apiserver-operator loadbalancer-serving-signer -o jsonpath='{.data.tls\.crt}' | base64 -d > $cluster-ca.pem
Change the kubeconfig file to include the extracted CA certificate. For example:
[virtwho-host]$ cat /root/.kube/config apiVersion: v1 clusters: - cluster: server: https://api.testcluster.example.org:6443 certificate-authority: /root/testcluster-ca.pem name: api-testcluster-example-org:6443 contexts: - context: cluster: api-test-cluster-example-org:6443 namespace: default
Before starting the service, you can test the configuration manually:
[virtwho-host]# virt-who --print
If the jq
program is installed, you can use it to make the output easier to read: # virt-who --print | jq
Enable the virt-who service:
[virtwho-host]# systemctl enable virt-who
Restart the virt-who service to use the new configuration.
[virtwho-host]# systemctl restart virt-who
Virt-who logs are available in /var/log/rhsm/rhsm.log
. In this file, you can view configuration or connectivity errors.
6.6. Registering virtual machines to use a host-based subscription
Register virtual machines with auto-attach so that they inherit a subscription from their hypervisor.
Prerequisites
- Attach a host-based subscription to the virtual machine’s hypervisor.
- Configure virt-who to query the virtual machine’s hypervisor.
- Ensure that all hypervisors the virtual machine can migrate to have host-based subscriptions attached and report to virt-who, or limit the virtual machine’s migration to specific hypervisors.
Web UI procedure
- Log in to the Customer Portal at https://access.redhat.com.
- Navigate to Subscriptions > Systems and click the name of the virtual machine.
- Click the Subscriptions tab.
- Click Run Auto-Attach.
Repeat these steps for each virtual machine.
CLI procedure
Register the virtual machine using the auto-attach option:
# subscription-manager register --auto-attach
- When prompted, enter your user name and password.
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.
6.7. Virt-who troubleshooting methods
Verifying virt-who status
Verify the status of the virt-who service:
# systemctl status virt-who.service
Debug logging
Check the /var/log/rhsm/rhsm.log
file, where virt-who logs all its activity by default.
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.
Testing configuration options
Make a change and test the result, repeating as needed. Virt-who provides three options to help test the configuration files, credentials, and connectivity to the virtualization platform:
-
The
virt-who --one-shot
command reads the configuration files, retrieves the list of virtual machines and sends it to the subscription management system, then exits immediately. -
The
virt-who --print
command reads the configuration files and prints the list of virtual machines, but does not send it to the subscription management system. Starting with RHEL 9 Beta, the
virt-who --status
command reads the configuration files and outputs a summary of the connection status for both the source and destination systems.-
The
virt-who --status
command with the--json
option provides additional connectivity data, in JSON format, for each configuration.
-
The
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.
- When the status report indicates a configuration success, the JSON output includes the number of hypervisors and guests that virt-who reported during its last successful run cycle.
- When the status report indicates a configuration failure, the JSON output includes the associated error message.
"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.
Identifying issues when using multiple virt-who configuration files
If you have multiple virt-who configuration files on one server, move one file at a time to a different directory while testing after each file move. If the issue no longer occurs, the cause is associated with the most recently moved file. After you have resolved the issue, return the virt-who configuration files to their original location.
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
Identifying duplicate hypervisors
Duplicate hypervisors can cause subscription and entitlement errors. Enter the following commands to check for duplicate hypervisors:
# 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.
Identifying duplicate virtual machines
Enter the following commands to check for duplicate virtual machines:
# 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
Checking the number of hypervisors
Enter the following commands to check the number of hypervisors virt-who currently reports:
# 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
Checking the number of virtual machines
Enter the following commands to check the number of virtual machines that virt-who currently reports:
# 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
6.8. Virt-who troubleshooting scenarios
Virt-who fails to connect to the virtualization platform
If virt-who fails to connect to the hypervisor or virtualization manager, check the Red Hat Subscription Manager log file /var/log/rhsm/rhsm.log
. If you find the message No route to host
, the hypervisor might be listening on the wrong port. In this case, modify the virt-who configuration file for that hypervisor and append the correct port number to the server
value.
You must restart the virt-who service after modifying a configuration file.
Virt-who fails to connect to the virtualization platform through an HTTP proxy on the local network
If virt-who cannot connect to the hypervisor or virtualization manager through an HTTP proxy, either configure the proxy to allow local traffic to pass through, or modify the virt-who service to use no proxy by adding the following line to ''/etc/virt-who.conf':
[system_environment] no_proxy=*
You must restart the virt-who service after modifying a configuration file.
The section [system_environment] is only supported from virt-who-0.30.x-1.el8 (RHEL 8.4), if you are using the old virt-who version, please set NO_PROXY by /etc/sysconfig/virt-who.
Chapter 7. Using Red Hat Subscription Manager
7.1. Understanding Red Hat Subscription Management
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.
Red Hat subscription services have moved from Red Hat Customer Portal to Red Hat Hybrid Cloud Console, however, your technical environment might require you to perform some tasks in the Customer Portal. For example, a user with a Red Hat Satellite Server on a disconnected network will continue to use the Customer Portal to create and manage subscription manifests. Also, a connected user without a Satellite Server will use the Customer Portal to enable simple content access for their organization.
If simple content access mode is enabled for your Red Hat organization, then you do not need to attach subscriptions or manage entitlements. The simple content access mode is enabled at the organization-level for new accounts by default. For information about enabling simple content access mode for an existing organization, see Enabling simple content access with Red Hat Subscription Management
While Red Hat products are available through a GNU Public License, Red Hat supports its products through a subscription-based license. Support includes:
- Downloadable content and updates
- Access to the knowledge base
- Support for your product
Red Hat Subscription Management provides administrators with the following information:
- Which products are available to your organization
- Which products are installed on your systems
- The status of your subscriptions
Red Hat Subscription Management allows administrators to identify the relationship between their systems and the subscriptions used by those systems from two different perspectives:
- All active subscriptions for an account and which systems are consuming them
- All systems profiled within the inventory and which subscriptions they are consuming
Additional resources
- For information about the changes and improvements to the subscription management platform, see Transition of Red Hat’s subscription services to console.redhat.com
- For more information about simple content access, see Getting Started with Simple Content Access.
- For information about how to register your RHEL system, see Getting Started with RHEL System Registration.
- For information about managing user roles for services hosted on the Hybrid Cloud Console, see User Access Configuration Guide for Role-based Access Control (RBAC).
7.2. Understanding your workflow for subscribing with Red Hat products
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:
- View or manage any systems for your account in the Systems inventory on the Red Hat Hybrid Cloud Console
- View or manage any subscriptions for your account in the Subscription Inventory on the Red Hat Hybrid Cloud Console
- Download software packages and updates from the content delivery network for as long as the subscription is active
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:
- An identity certificate for the system. This certificate is created when the system is registered. The system uses it to authenticate to the subscription service and periodically check for updates.
- A product certificate for each Red Hat product installed on the system. This certificate is installed on the system along with the product. It identifies the product, but it is not unique to the system.
- A subscription certificate for each subscription associated with the system. This certificate includes information about the subscription from the inventory.
Subscription management delivers better information and offers administrators better control over their infrastructures.
7.3. Tools and applications available for Red Hat Subscription Management
Red Hat Subscription services have moved from the Customer Portal to Red Hat Hybrid Cloud Console, however, your technical environment might require you to perform some tasks in the Customer Portal. For example, a user with a Red Hat Satellite Server on a disconnected network will continue to use the Customer Portal to create and manage subscription manifests.
All Red Hat Enterprise Linux subscriptions automatically include the following tools for managing the subscription configuration:
- Red Hat Subscription Manager client tools to manage local systems on the command line
- Subscription services on the Red Hat Hybrid Cloud Console to manage systems and subscriptions for your account
- Red Hat Satellite as an on-premise solution for systems that may not regularly check in
The diversity of tools allows administrators to create a workflow that fits both the business and infrastructure demands of their organization.
7.3.1. Red Hat Subscription Manager
Red Hat Subscription Manager tracks and displays what subscriptions are available to the local system and what subscriptions have been consumed by the local system. It works as a conduit back to the subscription service to synchronize changes, such as available product quantities or subscription expiration dates.
The Subscription Manager includes the following components:
- A UI-based client to manage the local machine
- A CLI client, which can be used with other applications or in automation scripts
These tools allow authorized users to perform tasks directly related to managing subscriptions, such as registering a system to Red Hat and updating the certificates required for authentication. Some minor operations, such as updating system facts, are available to help show and track available subscriptions.
You must have root privileges to run the Subscription Manager CLI tool because of the nature of the changes to the system. However, Subscription Manager connects to the subscription service as a user account for the subscription service.
The Subscription Manager is part of the firstboot process for configuring content and updates, but you can register the system at any time through the Subscription Manager UI or CLI. New subscriptions, new products, and updates can be viewed and applied to a system through the Subscription Manager tools.
Additional resources
- For information about how to register your RHEL system, see Getting Started with RHEL System Registration.
- For information about how to view and manage your subscriptions and their details, see Viewing and managing your subscription inventory on the Hybrid Cloud Console
7.3.1.1. Launching Red Hat Subscription Manager
You can run Red Hat Subscription Manager from the Red Hat Enterprise Linux UI. The following instructions show you how to run Subscription Manager from the RHEL UI based on the release version of your system:
- In RHEL 9, click Activities > Show Applications.
- In RHEL 8, click Activities > Show All Programs.
- In RHEL 7, click System Tools > Administration.
7.4. Viewing subscriptions with Red Hat Subscription Manager
To manage subscriptions, administrators need to know the following information:
- What subscriptions are available to the system
- What subscriptions are being used by the system
You can view your subscriptions and their details in the following ways:
-
From the command line interface (CLI) using the
subscription-manager
command - From the Subscription Inventory page on the Hybrid Cloud Console.
The following table shows options that you can use to manage your subscriptions with the subscription-manager
command.
Command | Description |
--installed (or nothing) | Lists all of the installed products on the system. If no option is given with 'list', it is the same as using the '--installed' argument. |
--consumed | Lists all of the subscriptions associated with the system. |
--available[-all] | Using '--available' alone lists all of the compatible, active subscriptions for the system. Using '--available --all' lists all options, even ones not compatible with the system. |
--ondate=YYYY-MM-DD | Shows subscriptions which are active and available on the specified date. This is only used with the '--available' option. If this is not used, then the command uses the current date. |
--installed | Lists all of the products that are installed on the system (and whether they have a subscription) and it lists all of the product subscriptions which are associated with the system (and whether those products are installed). |
Example 'list' showing subscriptions consumed
[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
Example 'list' showing all available subscriptions
[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
Additional resources
- For information about viewing your subscription inventory with the Hybrid Cloud Console GUI, see Viewing and managing your subscription inventory on the Hybrid Cloud Console
7.5. Using system purpose with Red Hat Subscription Manager
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
- Red Hat Enterprise Linux Server
- Red Hat Enterprise Linux Workstation
- Red Hat Enterprise Linux Compute Node
Service Level Agreement
- Premium
- Standard
- Self-Support
Usage
- Production
- Development/Test
- Disaster Recovery
Configuring system purpose offers the following benefits:
- In-depth system-level information for system administrators and business operations
- Reduced overhead when determining why a system was procured and its intended purpose
You can set system purpose data in any of the following ways:
- During activation key creation
- During image creation
- During installation using the Connect to Red Hat screen to register your system
- During installation using the syspurpose Kickstart command
- After installation using the subscription-manager CLI tool
Additional resources
- To configure system purpose with an activation key, see Creating an activation key.
- To configure system purpose with the Subscription Manager CLI tool, see Configuring System Purpose using the subscription-manager command-line tool
7.5.1. Listing available values for system purpose attributes
As the root user, you can enter the subscription-manager syspurpose
command and the role
, usage
, service-level
, or addons
subcommand with the --list
option to list available values for all system purpose attributes. Listing system purpose values for an unregistered system requires you to enter additional information on the command line.
The following examples show how to list the available system purposes values for the role attribute for registered and unregistered systems.
When the system is registered, enter the following command:
[root@localhost ~]# subscription-manager syspurpose role --list
When the system is unregistered, enter the following command with the --username
, --password
, --organization
, and --token
authentication options, as required:
[root@localhost ~]# subscription-manager syspurpose role --list --username=<username> --password=<password> --organization=<organization_ID> --token=<token>
where: The --username
option specifies the name of a user with organization administrator authority in your Red Hat account. The --password
option specifies the associated password. The --organization
option specifies the organization ID number. The --token
option specifies the token of the virt-who service account.
Specifying the organization ID is only required if you have multiple organizations and need to specify a particular organization.
Specifying the token is only required if you have configured virt-who to connect to OpenShift Virtualization.
When you enter the command on a registered system or on an unregistered system with authentication options, the expected output is the list of available values for the role attribute:
+-------------------------------------------+ Available role +-------------------------------------------+ - Red Hat Enterprise Linux Workstation - Red Hat Enterprise Linux Server - Red Hat Enterprise Linux Compute Node
System purpose addons are specific to your organization and do not appear in the list of available values. If you try to list available system purpose addons with the --list
option, then subscription-manager displays a warning message. For example:
# subscription-manager syspurpose addons --list There are no available values for the system purpose "addons" from the available subscriptions in this organization.
7.5.2. Setting custom values for system purpose attributes
If the value you want to set is not included in the list of valid values for the account, you can enter a custom system purpose value with the --set
option. To set a custom value, you must enter the command on a registered system or enter the command with authentication options on an unregistered system.
The following examples show how to set a custom value of “foo” for the system purpose role attribute on registered and unregistered systems.
When the system is registered, enter the following command:
[root@localhost ~]# subscription-manager syspurpose role --set=”foo”
When the system is unregistered, enter the following command with the --username
, --password
, --org
, and --token
authentication options, as required:
[root@localhost ~]# subscription-manager syspurpose role --set=”foo” --username=<username> --password=<password> --organization=<organization_ID> --token=<token>
where: The --username
option specifies the name of a user with organization administrator authority in your Red Hat account. The --password
option specifies the associated password. The --org
option specifies the organization ID number. The --token
option specifies the token of the virt-who service account.
Specifying the organization ID is only required if you have multiple organizations and need to specify a particular organization.
Specifying the token is only required if you have configured virt-who to connect to OpenShift Virtualization.
When you set a custom value on a registered system or on an unregistered system with authentication options, the expected output displays a warning message because the custom value is considered invalid. However, the output also displays a confirmation message because subscription-manager sets the custom value despite the warning.
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".
Subscription Manager only outputs the warning message if the system is registered or if you enter authentication credentials on an unregistered system. If your system is unregistered and you do not enter authentication options, Subscription Manager sets the custom value without displaying the warning message.
7.6. Enabling simple content access with Red Hat Subscription Management
If you use a Red Hat Satellite Server, then you can enable simple content access in the following ways:
- On a subscription manifest on the Red Hat Hybrid Cloud Console Manifests page.
- On a Satellite organization using the Satellite graphical user interface.
The simple content access setting on the Satellite organization supersedes the settings on the manifest.
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.
7.6.1. Enabling simple content access without a Red Hat Satellite Server
When you enable simple content access, you change the content access mode. You stop using the traditional mode, where you must attach a subscription to a system as a prerequisite of gaining access to content. You start using a new mode, where you can consume content regardless of the presence of an attached subscription.
Prerequisites
- The Organization Administrator role for the organization
Procedure
To enable simple content access for the directly connected systems in Red Hat Subscription Manager without a Satellite Server, complete the following steps:
- Log in to the Red Hat Customer Portal.
- On the Overview page, set the Simple content access for Red Hat switch to Enabled.
After you complete these steps, simple content access is enabled for all current and newly registered systems. Current systems will download the required simple content access certification information the next time that they check in to the subscription management services.
Additional resources
- For information about how to enable simple content access for a Satellite-supported system, see Setting the simple content access mode from Red Hat Hybrid Cloud Console.
7.7. Understanding errata
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.
7.7.1. Managing errata notification settings
Errata notifications are set as a preference for the user account, not for an individual system. When Red Hat Subscription Management 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.
Procedure
- From the Overview page, click the account name.
- Click Account Settings.
- Click Errata Notifications.
- Select the types of errata you want to receive. Security errata relate to critical security issues. Bug fixes and enhancement notifications relate to incremental updates to the product.
- Select the notification frequency.
- Click Save.
7.7.2. Troubleshooting errata applicability
If you see applicable errata displayed in Red Hat Subscription Management but have no yum updates available, it can mean one of a couple of settings are not correct.
Procedure
- Verify that you have the proper permissions to install all available updates on the system. If you do not have the necessary permissions, contact your organization administrator.
- If you are running RHEL 5 or RHEL 6.4 or earlier, please consider upgrading your system so that you can have the most up-to-date errata and system updates.
- Force a check in and run yum update again.* If the system has not been checked in recently, you may see a discrepancy between what you see in the Customer Portal and what is actually installed on your system.
# rm -f /var/lib/rhsm/packages/packages.json # service rhsmcertd stop # rhsmcertd --now # yum update
After forcing your system to check in again, please wait up to four hours for the errata data on Red Hat Subscription Management to update to their correct data.
Chapter 8. System Registration Terms and Concepts
The following list contains terms and concepts related to Red Hat tools and processes for registration, subscription management, and system management.
- access-based subscription model
- A subscription model enabled with the simple content access capability, through which access to subscription content is provided by the existence of a valid subscription and registration of the system.
- capacity
- The upper limit of usage for a subscription, expressed in the defined unit of measurement for a subscription.
- content
- Software product code and errata that is designed to be consumed on systems. Content can either be installed directly on systems or used with as-a-service delivery methods.
- content delivery network (CDN)
- A geographically distributed series of static webservers that contain subscription content and errata that is consumed by systems. The content can be consumed directly through subscription management tools such as Red Hat Subscription Management or through mirroring tools such as Red Hat Satellite.
- entitlement
- In the deprecated entitlement-based subscription model, one of a pre-defined number of allowances that is used during the registration process to assign, or attach, a subcription to a system. The entitlement-based subscription model is now superseded by the access-based subscription model of simple content access.
- entitlement-based subscription model
- A deprecated subscription model through which subscriptions are required to be attached on a per-system basis before access to subscription content is allowed.
- identity certificate
- Used by the system to authenticate to the subscription service to periodically check for updates. It is created when the system is registered.
- manifest
- A set of encrypted files containing subscription information that enables you to find, access, synchronize, and download content from the correct repositories for use in Red Hat Satellite Server organizations that are managed by a Satellite server.
- organization
- A customer entity that interacts with Red Hat. An organization is typically a company or a part of a company, such as a function, division, department, or some other grouping that is meaningful to that company.
- organization ID
- A unique numeric identifier for a customer’s Red Hat organization that is used in certain internal subscription management functions. This identifier is separate from the Red Hat account number that is associated with your organization. It is located on the Hybrid Cloud Console Activation Keys page.
- Red Hat account
- A set of credentials that is used to identify and authenticate a user to Red Hat. This account enables a user to log into Red Hat properties such as the Customer Portal and the Hybrid Cloud Console. Also referred to as a Red Hat login. A Red Hat account can be a member of the corporate account that is used by a corporation or part of a corporation, enabling a list of users, such as system administrators, purchasing agents, IT management, and so on, to centrally purchase subscriptions and administer systems. A Red Hat account can also be a personal account for a single user to purchase their own subscriptions and administer their own systems.
- Red Hat account number
- A unique numeric identifier associated with your Red Hat account.
- Red Hat Satellite
- A system management solution that allows you to deploy, configure and maintain your systems across physical, virtual, and cloud environments.
- Red Hat Subscription Management
-
A collection of tools available from several locations, including the
subscription-manager
command and options available from the Subscriptions menu of the Red Hat Hybrid Cloud Console. The subscription management tools provide views and functions that include subscription inventory, expiration, renewal, system registration, and others. - Red Hat Satellite Server
- A server that synchronizes content, including software packages, errata, and container images, from the Red Hat Customer Portal and other supported content sources. Satellite Server also provides life cycle management, access control, and subscription management functions.
- Satellite organization
- A Satellite-specific construct that is used to divide resources into logical groups based on ownership, purpose, content, security level, and so on. These Satellite organizations can be used to isolate content for groups of systems with common requirements.
- Red Hat Satellite Capsule Server
- A server that mirrors content from the Satellite Server to enable content federation across various geographical locations.
- registration
- The process by which you officially redeem your purchase of Red Hat software and services.
- remote host configuration (rhc)
-
A tool that enables system registration to subscription management tools, configuration management for the Red Hat Enterprise Linux connections to Red Hat Insights and management of Insights remediation tasks. It is not a replacement for the
insights-client
orsubscription-manager
. - repository
- A storage system for a collection of content. Repositories are organizational structures for software product content and errata in the Red Hat content delivery network.
- Satellite organization
- A Satellite-specific construct that is used to divide resources into logical groups based on ownership, purpose, content, security level, and so on. These Satellite organizations can be used to isolate content for groups of systems with common requirements.
- simple content access (SCA)
- A capability within Red Hat Satellite and Red Hat Subscription Management on the Customer Portal, used to enable access to subscription content. If a valid subscription exists, then registering a system grants access to that content. The preferred method to register content instead of the deprecated entitlement-based subscription model.
- system
- A physical or virtual machine.
- subscription
- A contract between Red Hat and a customer for a specified term that provides access to content, support, and the knowledge base.
- usage
- The measurement of the consumption of Red Hat products installed on physical hardware or its equivalent, measured with a unit of measurement that is defined within the terms of a subscription.
- utilization
- The percentage of the maximum capacity for a subscription that is exhausted by the usage of that subscription.
Providing feedback on Red Hat documentation
We appreciate your feedback on our documentation. To provide feedback, open a Jira issue that describes your concerns. Provide as much detail as possible so that your request can be addressed quickly.
Prerequisites
- You have a Red Hat Customer Portal account. This account enables you to log in to the Red Hat Jira Software instance. If you do not have an account, you will be prompted to create one.
Procedure
To provide your feedback, perform the following steps:
- Click the following link: Create Issue.
- In the Summary text box, enter a brief description of the issue.
- In the Description text box, provide more details about the issue. Include the URL where you found the issue.
- Provide information for any other required fields. Allow all fields that contain default information to remain at the defaults.
- Click Create to create the Jira issue for the documentation team.
A documentation issue will be created and routed to the appropriate documentation team. Thank you for taking the time to provide feedback.