Satellite 6: Managing physical and virt-who subscriptions
Virtual Datacenter subscriptions allow customers to subscribe all VMs running in a certain hypervisor. For that to work, Satellite generates a pool of derived subscriptions that are to be latter mapped to the running VMs. This mapping (assignment) only occurs if the virt-who daemon is properly configured to query the virtualization infrastructure to understand in which hypervisor a certain VM is running.
There is a very nice document (Subscription-manager for the former Red Hat Network User: Part 9 - A Case Study with activation keys) that covers in far more detail all options available; however I want to comment on a case that is prevalent if you are managing Red Hat products as well as internal products / repositories.
Imagine you:
- Need to provision physical servers that will consume a physical RHCI subscription.
- Need to provision virtual machines that will consume a derived/virt-who RHCI subscription.
- Need that all systems above access the same custom Products repositories.
For that you will need 3 activation keys :
- "ak-rhel7-physical-rhci"
- Autoattach: yes
- Subscriptions added: the pool(s) of RHCI subscriptions
- Product content: Enable the repositories from Red Hat products as required.
- "ak-rhel7-virtual-rhci"
- Autoattach: No
- Subscriptions
none
- Product content: Enable the repositories from Red Hat products as required.
- "ak-custom-products"
- Subscriptions: All of your required custom products
- Product content: Enable the repositories of your required products.
When provisioning and/or registering a system, just ensure you use both AKs simultaneously to ensure systems get access to their required software, for example:
subscription-manager register --org="Default_Organization" --activationkey=ak-rhel7-physical-rhci,ak-custom-products
If you are using Host Groups, edit each host group to use both activation keys so the provisioning will also use these.
Note that the first AK you specify will be used to set the Content View, Enviroment (Library, ...), Service Level, etc of your content host. Also this does not mean multiple content views can be used; the only CV used by content hosts is the specified in your first AK.
This also solves the problem of virt-who not sending the VM-to-host mapping while provisioning. With no subscriptions associated to the AK for virtual systems, Satellite will generate a temporary 1day/1week subscription with access to all available Red Hat products within Satellite. This gives virt-who plenty of time to generate and assign the derived VDC subscriptions.
tl;dr Don't try to do everything at once in a single AK, just use multiple AKs and ensure each one does it part well.
Happy hacking!