New VMs registered to Satellite 6 only get base Repo

Latest response

Initially I was able to successfully register a new RHEL 7 VM (vmware-based) to the new satellite 6 server but got the message about a guest license. I followed this kb article ( to get virt-who configured and running. I have to do almost everything via a proxy server due to our networking policies, however the new VM did connect to the vcenter and pull down all the hypervisor information and I can see all of that in my Satellite server.

The problem is that the VM still only gets the base RHEL 7 repo and none of the other channels. I have the content views created that include all of those additional channels (Extra RPMs, Optional, supplementary, Common).

I have my satellite server also registered with a different activation key that would include the Satellite repos and it also only gets the base channel.

I have verified that I can go into the newly registered host and click on the product content tab and override the defaults and then that VM will get the new repos. But I don't want to have to override on a case by case basis like that.

Why are my content views not being honored when registering a new VM? Is this due to the auto-attach? That seems to only be for subscriptions and not specific repos.


If using a registration key for the clients you can force it to override and enable the repos you want. I had the same issue and ended up using registration keys. It gets tricky when using the virt-who and data center licenses because you have to assign all of the Red Hat Enterprise Linux for Virtual Datacenters, Premium (DERIVED SKU), or other such licenses to that registration key before using it otherwise the repos tend to not get enabled.

Is that a switch on the command line? I did create an activation key based on the content view that contains all the repos I want to provide, but I'll initially get the message "Guest has not been reported on any host and is using a temporary unmapped guest subscription".

I can make it fully "subscribed" if I enable the virt-who service and let it get all the hypervisor info, but it still doesn't enable any other repo.

What's odd is that if I do subscription-manager repos, I see all the repos, but they're all disabled except the main server rpm repo. I could probably just enable them in yum, but it's very confusing that on the content host page for the server I've registered it specifically tells you to use the repos page to enable repos, not to override the defaults.

It's almost like if you were using Satellite 5 and didn't connect the child channels to the parent. I just can't figure out where you do that in version 6.

I think you need to configure your activation key:

  • add subscriptions
  • then enable the associated repositories under the product tab

Then when you register your system with this activation key, you should have access to what you defined.

For a previously registered system you can either re-register the system (subscription-manager register --force --activationkey $YOURKEY) or simply activate the missing repos with "subscription-manager repos --enable $repo1 --enable $repo2".

Hope this help.

Thanks, that was it. I didn't realize I had to specifically attach a subscription to the activation key. I thought the auto-attach function was doing that.

Also not sure how this all works when, since it's a VM, it picks up the virtual guest subscription anyway.

Same problem here,solved as suggested but adding one by one ALL datacenter licenses to the activation-key is a tedious process.

I'll try to explain.

Firstly, a registering system can use either username/password or activation-key to register. For the sake of simplicity, let's use the activation-key use case.

An activation key is fundamentally a registration token that allows you to register using it in lieu of username/password. In addition, they can do a number of interesting things that you'd usually want to do at registration time, such as:

  • Attach a subscription: This is critical because without a subscription that grants access to repos, you cannot access them. (This is true for both Red Hat content types, and non Red Hat types). Note: there are multiple methods that can be used to attach subscriptions, which are outlined in this KCS Activation Key Enhancements with Red Hat Satellite 6.1
  • Set Product Content: An activation key can enable/disable a repository at registration time. By default, most Red Hat repos (except the OS repo) are usually disabled. (And most non Red Hat repos default to enabled). Product content overrides apply ONLY at registration time. Setting them does not retroactively apply to systems that have previously used that key to register.

For virtual machines that are registering, you have an additional variable: host/guest mapping. That is, which hypervisor does the guest reside on. The host/guest mapping data is provided by the virt-who daemon, which runs periodically on most platforms (and is event driven on some platforms such as VMWare). In order to use a vDC/unlimited subscription, Satellite needs to know which hypervisor does the guest reside on (so that it can assure that the guest uses the correct subscription), and it is virt-who which provides this data.

At registration time, it is somewhat likely that the hypervisor that the guest is running on is unknown (it may have been instantiated between two runs of virt-who, and hasn't been reported yet). In your example, which I am assuming you have some number of hypervisors which you provision RHEL workloads on, you don't have to add EACH datacenter subscription to the activation key.

When you add Red Hat subscriptions to an activation key and that key has the 'auto-attach' property set to 'true' (which it is by default), the behavior of the key is 'pick an appropriate subscription from the list', which seems like it is exactly what you want, but it points out an issue: What happens if it cannot pick an appropriate subscription? In the case of a freshly provisioned virtual machine (which isn't reported via virt-who yet), none of your datacenter subscriptions are 'appropriate' (since we don't know what hypervisor the guest is on), and thus registration fails. Previously, in Satellite 6.0 there were only two (equally bad) ways to avoid this:

  • make virt-who polls very frequently (by setting the VIRTWHO_INTERVAL very low)
  • adding an artificial wait in your provisioning template which is greater than the VIRTWHO_INTERVAL to ensure the machine was properly reported.

Since Satellite 6.1, we've introduced the 'Temporary Unmapped Guest Subscription', which allows a virtual machine, which has not been reported via virt-who to register and consume content for a period of time of 24 hours. This allows transient failures in virt-who (the daemon crashed, the system virt-who runs on being offline for maintenance, etc) to not impact your ability to successfully provision a virtual system.

However, this requires some changes to your activation keys. Your current workflow is:

  • configure virt-who
  • add hypervisor
  • attach subscription to hypervisor (which unlocks the 'DERIVED_SKU')
  • attach 'DERIVED_SKU' subscription to activation key
  • repeat for all hypervisors (and for newly added hypervisors).

This process changes to:

  • configure virt-who
  • add hypervisor
  • attach subscription to hypervisor (which unlocks the 'DERIVED_SKU')
  • repeat for all hypervisors (and for newly added hypervisors).

Finally, and in very succinct terms, create exactly ONE activation key, with NO subscriptions attached, and use it for registration. This will give your guests the correct subscription of the hypervisor they reside on (if known via virt-who), OR the 24 hour Unmapped Guest Sub (if not).

Note: you actually don't have to explicitly attach the subscriptions to the hypervisors. A guest, if known via virt-who and is running on a hypervisor without a subscription WILL attach a subscription that properly subscribes both itself AND the hypervisor. However, most people want to be explicit about which hypervisors consumes which subscriptions, so explicitly assigning the subscriptions to the hypervisors works too.

Hey Rich, Thanks for this explanation. It sure makes a lot of sense. However, it still does not allow one to select product overrides on the activation keys, since there's no Subscription attached to the Activation Key. Any way to work around this? Thanks

I have this exact issue. Without having a subscription selected in the activation key (all subs on this customer are vDC) how do you override repositories? The 'Repository Set' options are only made available when a subscription is added to the key?

This is causing problems, specifically because I want to enforce EUS repositories only.

It seems you can do it by command line now (I have not tested it yet):


hammer activation-key add-subscription --id ak_ID --subscription-id sub_ID

Thank you. In any case, for every new VMware host, you need to add: - a subscription to it under Content Host - a subscription to the various Activation Keys

In the past (Satellite 5), license issues was almost zero.

You explicitly do NOT have to add the vDC (or other similar) subscriptions to the activation key. In fact doing so puts you into a race condition, where your clients will sporadically fail to properly register.

This is documented in the KCS titled 'Activation Key Enhancements in Red Hat Satellite 6.1', specifically the Real World Use Case 2 section.

If I want an host subscribed to third-parts repo (like EPEL) since its registration, do I need to add the subscription to the activation key or not?

Activation keys are used only at registration. For a host that is already registered, You need to apply the subscription to the host itself (via hosts->content hosts->YOUR_HOST->subscriptions)

Ideally, you add the subscription to the activation key so that newly provisioned/registered hosts will get the correct subscription attached. (and no further work is required in this usage)

OK, clear. In any case, in a situation with all VMware VMs, having even one subscription in the activation key, breaks the registration during deployment. I solved following the suggestion in the article: "create exactly ONE activation key, with NO subscriptions attached, and use it for registration"

I have 2 questions around the activation keys, i'm running satellite 6.2.7 1. for vDC, i have to manully go to each vmware esxi host in hosts > content hosts > subscriptions and add one vdc subscription, correct? This is what I've done and seems to work well.

Where i have an issue is getting the rhel-7-server-satellite-tools-6.2-rpms sub to attach consistently during provisioning. which if it doesn't attach all my post config fails because katello and puppet rpms are in that repo. I use auto-attach for base rhel clients, ie i have a activation key called act-rhel-7server and it's set to auto-attach.

  1. If I'm adding a custom product, say, postgres, should I create a 2nd key called postgres, and manually add that postgres sub and choose the right repos to enable, then add both keys to my hostgroup? So i'd have a postgress hostgroup, that as my OS rhel 7 key that auto-attaches and the new custom product key for postgres.

It seems to fail intermittently fail to attach the satellite tools if I try to use a single key (has both os and db added) and is a mixture of auto-attach. If i create 2 keys it seems to work consistently. Is this the best approach?

Yes. Two keys here are preferred here as your first key needs to have auto-attach = true and no subscriptions attached. (None. No Red Hat Subs. No Custom Subs). This allows the guest to get a subscription of its hypervisor (which you've been attaching subs to explicitly) AND if the guest hasn't been reported yet, consume a temporary subscription. (Read: a key created in this manner will ensure that a system will always get a subscription [and thus have access to the Satellite-tools repo])

This is documented in use case #2 of this doc (

And you put your custom product on the second key. Lastly, set both on the hostgroup.

Thanks Rich! This is exactly what I thought I needed to do. i've tried both single key and 2 keys and the 2 keys with my rhel key set to auto-attach and no sub and my 'app/custom' key set specifically has always worked consistently but using single key I always had issues.

Thanks again for the quick reply.

Also a big thanks to you Rich! It cut the gordian knot :)

I still run into issues with subscriptions with vCenter and Satellite 6. For example, in addition to needing rhel-6-server-rpms and rhel-6-server-satellite-tools-6.2-rpms enabled, I need to have the the rhel-6-server-optional-rpms repo enabled.

If I use a single activation key with auto-attach=true and no subs attached at all, i get this after provisioning, where the 2 repos are enable and the optional is available but not enabled. How can I enable the optional repo on provisioning?

[root@myclientserver ~]# subscription-manager repos --list
    Available Repositories in /etc/yum.repos.d/redhat.repo
Repo ID:   rhel-6-server-satellite-tools-6.2-rpms
Repo Name: Red Hat Satellite Tools 6.2 (for RHEL 6 Server) (RPMs)
Repo URL:$basearch/sat-t
Enabled:   1

Repo ID:   rhel-6-server-rpms
Repo Name: Red Hat Enterprise Linux 6 Server (RPMs)
Repo URL:$releasever/$basearch/o
Enabled:   1

Repo ID:   rhel-6-server-extras-rpms
Repo Name: Red Hat Enterprise Linux 6 Server - Extras (RPMs)
Repo URL:$basearch/extra
Enabled:   0

Repo ID:   rhel-6-server-optional-rpms
Repo Name: Red Hat Enterprise Linux 6 Server - Optional (RPMs)
Repo URL:$releasever/$basearch/o
Enabled:   0

Repo ID:   rhel-server-rhscl-6-rpms
Repo Name: Red Hat Software Collections RPMs for Red Hat Enterprise Linux 6 Server
Repo URL:$releasever/$basearch/r
Enabled:   0

but in my hostgroup, i also need to add vmware tools (or any other custom repo). So when I then have my 2 activation keys listed in my host group (1 set to auto attach w/no subs added, 2nd custom key for vmware tools and onlythat repo enabled) I get the repos below. Notice all the repos are enabled but then none of the other repos, like Optional or Extras are even available to enable?

<br />[tmtw1@myclientserver ~]$ sudo subscription-manager repos --list
    Available Repositories in /etc/yum.repos.d/redhat.repo
Repo ID:   rhel-6-server-satellite-tools-6.2-rpms
Repo Name: Red Hat Satellite Tools 6.2 (for RHEL 6 Server) (RPMs)
Repo URL:$b
Enabled:   1

Repo ID:   rhel-6-server-rpms
Repo Name: Red Hat Enterprise Linux 6 Server (RPMs)
Repo URL:$b
Enabled:   1

Repo ID:   mycustomREPO_VMware_Tools_RHEL6_rhel6_x86_64_index_html
Repo Name: rhel6 x86_64 index.html
Repo URL:
Enabled:   1

So why doesn't this show the other Optional repo at least available? What is the proper method to enable the red hat repos I need, ie server, sat tools, and optional, along with a custom repo? I've tried almost every combination of key and subs and nothing seems to work.

Please provide any information on how to acheive this and how to avoid the optional repo not even being available to enable?

thanks, Todd


do you get an answer/find a solution for the first issue regarding how to enable rhel-7-server-satellite-tools-6.2-rpm and other channels with activation key for a guest with Datacenter licence ?

Yes, I just use the auto-attach. If I have a custom product, I create a 2nd key. This works very well. The 'os' key with auto-attach add the tools repo and then my 2nd key adds whatever custom product, like postgres.

Hi! It's still not clear to me how i do enable product content "Red Hat Enterprise Linux 7 Server - Extras (RPMs)" to hosts which use a VDC subscription?! The hypervisor is properly subscribed with "Red Hat Enterprise Linux for Virtual Datacenters, Premium". A new hosts running on that hypervisor gets "Red Hat Enterprise Linux Server with Smart Management" and activated product content "Red Hat Enterprise Linux 7 Server (RPMs)". Ok! But i need "Red Hat Enterprise Linux 7 Server - Extras (RPMs)" enabled too! How can i achive that??

BTW: Enabling custom repo like EPEL etc. works fine through second activation key.

Cheers Dirk

Dirk, I suggest you check if the Extras repository has been added to the server's Content View. I checked our Satellite and that is what I would do to fix it. Cheers and good luck!

Attention! There is a known bug with vDC licenses-only! You need to manually attach a subscription to the Activation Key, enable desired repos and then remove the subscription.

I am having an issue trying to run yum repolist on a new registered client on my disconnected satellite 6.2.12 server. I first self registered the sat server and ran a yum update with some issues with broken packages. Then I ran the yum update --skip-broken option which seems to complete. Then I registered my first client and ran a yum -y update with no issues. Now, I am running through the following error with any other client "The SSL certificate failed verification".

Red Hat Enterprise Linux for Virtual Datacenters with Smart Management ( standard and premium), we have moving the redhat guests araound different hypervisor, but satellite is not auto updating the subscriptions, is there any to run a single hammer command to attach around 100 systems on single time..