When you register a guest from Openstack, Satellite thinks the guest is a physical machine. The BIOS info from the hardware page is found below. Vendor: Seabios System: OpenStack Nova 2013.2-5.el6ost Product: OpenStack Nova Bios: Seabios 0.5.1 01/01/2007
Please see attached file as a full dmidecode output from an instance running on OpenStack
Created attachment 839024 [details] OpenStack guest dmidecode output
(In reply to Matthew Davis from comment #0) > When you register a guest from Openstack, Satellite thinks the guest is a > physical machine. > > The BIOS info from the hardware page is found below. > > Vendor: Seabios > System: OpenStack Nova 2013.2-5.el6ost > Product: OpenStack Nova > Bios: Seabios 0.5.1 01/01/2007 Current values from openstack-nova-common-2013.2.1-2.el6ost.noarch.rpm are: $ cat release [Nova] vendor = Red Hat Inc. product = OpenStack Nova package = 2.el6ost
So, end state is that OpenStack will identify itself as: vendor = Red Hat product = OpenStack Compute This matches data placed into RHN Hosted BZ - bug 1061805
Note to QE: currently running versions of OpenStack do not inject the strings agreed upon in comment 9 into the guest's bios information, so their guests will not be recognized as guests and will still consume physical entitlements. Future versions of the OpenStack hypervisor will be updated with the new bios information, so this will only work with new versions of OpenStack. Committed to Spacewalk master: 9a825833d99328a6d3fde4c4bd06774b39926829 Fixed in Spacewalk rpm: spacewalk-backend-2.1.52-1
(In reply to Stephen Gordon from comment #8) > (In reply to Matthew Davis from comment #0) > > When you register a guest from Openstack, Satellite thinks the guest is a > > physical machine. > > > > The BIOS info from the hardware page is found below. > > > > Vendor: Seabios > > System: OpenStack Nova 2013.2-5.el6ost > > Product: OpenStack Nova > > Bios: Seabios 0.5.1 01/01/2007 > > Current values from openstack-nova-common-2013.2.1-2.el6ost.noarch.rpm are: > > $ cat release > [Nova] > vendor = Red Hat Inc. > product = OpenStack Nova > package = 2.el6ost After talking to Stephen Herr on IRC I conferred with Alan Pevec and believe the naming of the above Nova configuration values has caused some confusion here. 'vendor' in the above gets translated into 'manufacturer' in the Libvirt XML. 'product' in the above gets translated into the 'product' field in the Libvirt XML. Stephen does this match your implementation or am I correct in guessing we might have had a miscommunication here?
No it does not, I'll have to update the code to look for "Red Hat" in the manufacturer field instead of vendor. Thanks for the heads up. Stephen, is it possible on your side to put a comment in your config file, something to the effect of "Don't change these two values, RHN Hosted and RH Satellite depend on these to recognize the systems as virtual guests."? We've had problems before where a year or two down the road someone who doesn't know / remember how this all works will decide to change things, and we should be able to prevent that class of problems with a simple comment.
(In reply to Stephen Herr from comment #12) > No it does not, I'll have to update the code to look for "Red Hat" in the > manufacturer field instead of vendor. Thanks for the heads up. > > Stephen, is it possible on your side to put a comment in your config file, > something to the effect of "Don't change these two values, RHN Hosted and RH > Satellite depend on these to recognize the systems as virtual guests."? > We've had problems before where a year or two down the road someone who > doesn't know / remember how this all works will decide to change things, and > we should be able to prevent that class of problems with a simple comment. Right so to be explicit given our decision to change the strings from what's currently there in the config I pased this means on your end it will be: manufacturer = "Red Hat" product = "OpenStack Compute" We'll get a comment added to the Nova config when we change it to the above.
Second commit to Spacewalk master: b010979b17fc1b966a93b3d5c74b434364448832 spacewalk-backend-2.1.53-1
Third commit to Spacewalk master: 323e5f2a84bc39b65dabaa26700e30a1d336cd5c Not all machines provide manufacturer (like physical ppc64 machines). Code was not None safe.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2014-0319.html