SAM - Subscription Asset Manager

Latest response

Hi everyone,

  I was wondering how many of you are using or have considered using SAM(1)(2) for managing your subscriptions?  I have recently become involved with setting it up and troubleshooting it and wanted to find out from the broader community if you are using it, and would you care to share your experience?

 

Kind Regards,

Jim

 

(1) https://access.redhat.com/knowledge/solutions/70584

(2) https://access.redhat.com/knowledge/videos/214863

Responses

Whatever you do, do NOT subscribe your Satellite server to the SAM channel and do an update. It will install incompatible versions of Quartz and SLF4J and breaks Taskomatic, RHN-search, as well as the Tomcat pages.

An overview of Red Hat Subscription Management including Certificate-based Subscription Management (such as SAM) vs. RHN Classic Subscription Management (such as Satellite) can be found here:

https://access.redhat.com/knowledge/articles/143253

I'm testing SAM in my environment with RHEV and linux servers. 
In example - I have one RHEL 5.9 x64 box subscribed correctly to SAM:
# subscription-manager list --consumed

+-------------------------------------------+
   Consumed Subscriptions
+-------------------------------------------+
Subscription Name:      Red Hat Enterprise Linux Server, Standard (1-2 sockets) (Unlimited guests)
Provides:               Red Hat Enterprise Linux Server
                        Red Hat Beta
SKU:                    RH01xxxxx
Contract:               10xxxxxx
Account:                7xxxxx
Serial Number:          48xxxxxxxxxxxxxxxxxx
Active:                 True
Quantity Used:          1
Service Level:          Standard
Service Type:           L1-L3
Starts:                 12/27/2012
Ends:                   12/27/2017


Everything seems to be correct except:

# subscription-manager list
No installed products to list

# subscription-manager repos
This system has no repositories available through subscriptions.

No clue what to do with that.

Another problem is RHEV - integration between SAM and Hypervisors (installed via ISO) is a pain in the *s.
As SAM checks VM's and Hosts, and assigns a Vrtual subscrption if Host has valid subscritpion
Virtual Guest subscriptions shows and disapears.

Also every hypervisor update makes you go thru subscribing hypervisors again. Pain.

Did that occur? If so, what could we have put in the docs to avoid it?

-- bk

[Duplicate comment removed -Admin]

How did you provision the machine? 

I just unregistered it from RHN Classics (deleted system_id, ect), installed the RPM that prepares SAM and made subcritpion-manager register and then subscribe/attach.

ok.. so you are a satellite user, or are you using hosted?

 

There is a tool called subscription-manager-migration. What this tool will do is pull down the appropriate product certificates which are used by subscription-manager is order to know what is installed on your machine. Try connecting your machine back and then migrate it using the the migration tool and let me know how it goes. 

The official docs are at https://access.redhat.com/site/documentation/en-US/Red_Hat_Subscription_Management/1.0/html/Subscription_Management_Guide/rhn-migration.html

 

-- bk

Hi,

We try to use SAM as subscrption manager for our RHEV cloud. We are trying to implement this solution for the 3rd time now.

We are having 3 hosts with RHEV and Unlimited Guests Subscriptions - 90% ov Virtual Machines (VM) are RHEL 6 - and I'm referring to those.

As long as we keeping out Virtual Machines in a farm (not cloud) environment (we are pinning virtual machines to hosts) subscriptions works in most time.

But if we are using the all cloud features like migration, load-balancing, power and resources balacing - we can't update our systems any more - all we receive in yum is the message from SAM - Forbidden 403 - as the vm is pinned to host it were it was created on. What's more after a while we could only update virtual machines while thy migrate to strongest server (quad socket) - otherwise we received from SAM - Forbidden 403. So the concept of pinning the VM to a virtualisation host in a cloud is missed or badly implemented.

As for now - for us - SAM is totally immature, and I would not reccomend or recommend avoiding using it within RHEV Cloud Solution.