Problem:
I have foreman/katello running with redhat manifest subscriptions. I have several subscriptions from redhat, one being “Red Hat Gluster Storage, Premium (2 Physical or Virtual Nodes + 1 Physical or Virtual Node for quorum setup)”, another being “Red Hat Enterprise Linux for Virtual Datacenters, Premium”.
When I subscribe a new virtual server via an activation key that has auto-attach and no configured subscriptions configured, that server gets a subscription from “Red Hat Gluster Storage, Premium (2 Physical or Virtual Nodes + 1 Physical or Virtual Node for quorum setup)”, not a temporary one.
After that, virt-who comes by and detects the server belongs to an already known vmware server but the subscription still stays wrong.
Expected outcome:
The temporary 24 hour subscription should be used and when virt-who has ran, it should use a guest subscription from “Red Hat Enterprise Linux for Virtual Datacenters, Premium”
Foreman and Proxy versions:
1.23.0 + supported Katello version
Two points here that I think explain what you’re seeing:
The virt-who checkin will not reconcile subscriptions on the virtual guest. ie if there is a valid subscription already attached, it won’t remove one to attach another that is a better match (the temp sub you are referring to).
In order to use the VDC (Virtual Datacenter) subscription correctly it should be attached to the hypervisor of the virtual guests. From that point I believe auto-attach will subscribe the guests to the temporary subscriptions of the VDC sub.
The steps to correct would be:
Attach the VDC subscription to your hypervisor(s)
Remove existing subscriptions from your virtual guests (you can do this in bulk from the Content Hosts list as far as I know)
Run auto-attach on your virtual guests (also doable in bulk from the Content Hosts list)
The VDC subscription was already attached to my hypervisor, and removing+running auto-attach works (that’s what I tried myself too). But that is of course no solution for new clients, which again get no temporary subscription but “Red Hat Gluster Storage, Premium (2 Physical or Virtual Nodes + 1 Physical or Virtual Node for quorum setup)”.
I think there’s a possible order of operations issue. The virt-who checkin needs to happen between the hypervisor being subscribed with the VDC SKU and the guest being registered with an activation key that does not have any subscriptions attached.
Well, that would render it all useless … it is impossible to do a virt-who checkin for each server being provisioned while the server is still being installed. We do a basic install, then comes something like a primitive ansible, registers the server and continues to install other stuff.
However, this all happens during the first 10 minutes after the server is created, meaning we would need to somehow pause the install after the server is created in vmware, do virt-who and then continue. All while redhat is saying something totally different (normally virt-who checks in once an hour). The article https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/virtual_instances_guide/introduction (chapter 1.3) says the same as the other redhat article, but chapter 1.5 says something different (section about “status yellow”) with their temporary subscriptions.
So they say a server gets a temporary subscription if the hypervisor doesn’t know about the virtual server yet … the article you mention (and their chapter 1.3) seems to contradict this a bit.
So: how to handle a new virtual server installation, subscriptions and then further server install?
we have faced a simmilar issue in the past. Our current workaround was to remove any and all unneeded subscriptions from the manifest, which was no big deal for us since we only have per-hypervisor subscriptions anyways and new hypervisors for “special” subscriptions don’t get deployed that often. We have to update the manifest everytime a new hypervisor is deployed, though, which might be unpractical for you.
If that is no solution for you, you could also assign all your “guest of hypervisor” subscriptions to an activation key and use that for registration. I have not testet this myself by now, but from what I’ve read this should ensure the new guests recieve the correct subscription. I would recommend using the same key for at least the subscriptions and auto-attach. If practical to you, setting lifecycle environment and content view on the same key should also be a good idea. That way you should be able to avoid race conditions (like subscription-manager doing auto-attach via one key while the one with the subscriptions is not yet processed). In the scenario, you will have to update your activation-keys for any newly deployed hypervisor, though.
From what I understand, system purpose was ment to avoid this kind of issue without jumping through any of these hoops. I don’t have any experience with that by now and it looks like the available system purposes are currently very limited, but it could be worth taking a look at. If you want to try it, you can find the documentation here.
your workaround won’t work in our case since the “Red Hat Gluster Storage, Premium (2 Physical or Virtual Nodes + 1 Physical or Virtual Node for quorum setup)” subscription is also being used.
Your second solution won’t work as well, since we need the VDC subscription (we have a whole lot of virtual servers, that are only covered by a VDC subscription, we don’t have another subscription that covers that many seperate servers …
System purpose might help a little bit during auto-attach (not sure), but the real issue seems to be that no temporary subscriptions are being given, so in the end this seems like a bug to me.
I’m going to think about this some more, but I’m guessing not a lot of people use Redhat manifests with Katello during vm-server deployment, since this would block a lot of people.
