FranGarcia.me (Posts about subscriptions)https://www.frangarcia.me/categories/subscriptions.atom2023-07-01T22:22:34ZFran GarciaNikolaSatellite 6: Managing physical and virt-who subscriptionshttps://www.frangarcia.me/posts/satellite-6-managing-physical-and-virt-who-subscriptions/2018-02-09T12:20:14+01:002018-02-09T12:20:14+01:00Fran Garcia<p>Virtual Datacenter subscriptions allow customers to subscribe all VMs running
in a certain hypervisor. For that to work, Satellite generates a pool of
<em>derived subscriptions</em> 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.</p>
<p>There is a very nice document
(<a href="https://access.redhat.com/blogs/1169563/posts/2867891">Subscription-manager for the former Red Hat Network User: Part 9 - A Case Study with activation keys</a>)
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.</p>
<p>Imagine you:</p>
<ul>
<li>Need to provision physical servers that will consume a physical RHCI subscription.</li>
<li>Need to provision virtual machines that will consume a derived/virt-who RHCI subscription.</li>
<li>Need that all systems above access the same custom Products repositories.</li>
</ul>
<p>For that you will need 3 activation keys :</p>
<ul>
<li>"ak-rhel7-physical-rhci"<ul>
<li>Autoattach: yes</li>
<li>Subscriptions added: the pool(s) of RHCI subscriptions</li>
<li>Product content: Enable the repositories from Red Hat products as required. </li>
</ul>
</li>
<li>"ak-rhel7-virtual-rhci"<ul>
<li>Autoattach: No</li>
<li>Subscriptions <code>none</code></li>
<li>Product content: Enable the repositories from Red Hat products as required. </li>
</ul>
</li>
<li>"ak-custom-products"<ul>
<li>Subscriptions: All of your required custom products</li>
<li>Product content: Enable the repositories of your required products.</li>
</ul>
</li>
</ul>
<p>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:</p>
<div class="code"><pre class="code literal-block"><span class="n">subscription</span><span class="o">-</span><span class="n">manager</span><span class="w"> </span><span class="n">register</span><span class="w"> </span><span class="o">--</span><span class="n">org</span><span class="o">=</span><span class="s">"Default_Organization"</span><span class="w"> </span><span class="o">--</span><span class="n">activationkey</span><span class="o">=</span><span class="n">ak</span><span class="o">-</span><span class="n">rhel7</span><span class="o">-</span><span class="n">physical</span><span class="o">-</span><span class="n">rhci</span><span class="p">,</span><span class="n">ak</span><span class="o">-</span><span class="n">custom</span><span class="o">-</span><span class="n">products</span>
</pre></div>
<p>If you are using Host Groups, edit each host group to use both activation keys
so the provisioning will also use these.</p>
<p>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.</p>
<p>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.</p>
<p><strong>tl;dr</strong> Don't try to do everything at once in a single AK, just use multiple
AKs and ensure each one does it part well.</p>
<p>Happy hacking!</p>