Bug 501440

+++ This bug was initially created as a clone of Bug #496147 +++

This request is to in addition to the guest's UUID also export the *host's* UUID through the SMBIOS to the guest.

This is needed in order to establish RHN business rules that will allow using a *guest* centric model, in which the host is *not* registered in RHN. 

The the current model for identifying virtual guests and the entitlement they should be consuming, relies on the host itself being registered in RHN and then comparing the guest UUIDS it reports with the actual guests registering. That does not work for a model where the hosts are not registered or are even not able to communicate outside a locked-down management network.

The premier use case is RHEV-H, where the host is not registered in RHN. Other use-cases might include other virtualization platforms.

RHN would use the host UUID to find guests sharing a host.

A requirement for this is, that the SMBIOS reflects the host the guest is actually running on (vs. the one it was booted on and the possibly migrated away from).

--- Additional comment from berrange on 2009-04-17 07:54:57 EDT ---

As per bug 495612, exposing the host UUID to the guest is not the right approach. If RHN needs to know host <-> guest placement, then the external management app (vdsm or RHEV-M) should be providing this, so that it accurately reflects current host<-> guest placement, and can be correlated with the guest UUID already made available to the guest.

--- Additional comment from dlaor on 2009-04-19 08:44:56 EDT ---

This is wrong. The guest is not bound to the host and can live-migrate into lots of other hosts.
RHEV-M (not vdsm) is the source of this data. IMO this should not be exposed to the guest through the hypervisor interface.

--- Additional comment from riek on 2009-04-21 00:18:14 EDT ---

Reopening. This is a hard requirement from the RHEL guest environment. Without this, the business rules for RHEV can not be implemented.

The RHN team and PM are well aware that guests can be migrated. Therefore the SMBIOS information should be updated when the host is migrated.

This is required for RHEL guests, RHEL guests don't talk to RHEV-M.

--- Additional comment from riek on 2009-04-21 00:23:27 EDT ---

Re comment 1: making the guest provisioning dependent on the management system is broken in several ways: 
* it introduces uncontrollable dependencies,
* a delivery is impossible within the timeframe of this project (GA in June)
* it depends on the customer using RHEV-M, that is a lock-in that limits the use cases for RHEV-H in an inacceptable way.

Also, the mechanisms that are planned to identify the host in this way, will be considered for other models where we don't control the host or the management (e.g. VMWare, Blade Center Pricing).

--- Additional comment from ehabkost on 2009-04-27 10:23:58 EDT ---

Moving back to NEW, as the bug assignee (me) is not the one working on it.

--- Additional comment from dlaor on 2009-04-27 10:34:23 EDT ---

Ok, after discussing it on email we'll approach it this way +-:

- Gleb will add -smbios backport code:
  http://svn.savannah.gnu.org/viewvc/?view=rev&root=qemu&revision=7163
- Since there is no option of the above code to write the host uuid,
  we either need to take over one of the above fields or send a new patch
  to qemu that will allow adding another table.
  Let's try the second option first.

Apart to that we need to harden smbios to pass svvp, we have another BZ for it.

--- Additional comment from ykaul on 2009-04-27 11:15:57 EDT ---

Dor, we also need BZ(s) filed for RHEV-M to support passing all this to VDSM, which in turn needs BZ(s) to implement this on their side as well...

--- Additional comment from ehabkost on 2009-04-28 11:40:13 EDT ---

Created an attachment (id=341593)
76e6184794f4006008af40357109381ae526dae3 qemu: Add support for SMBIOS command line options (Alex Williamson)

Patch that is currently on the git patch queue.

--- Additional comment from ehabkost on 2009-04-28 11:40:17 EDT ---

Patch posted for review and queued. Changing status to POST

--- Additional comment from aarcange on 2009-05-08 13:39:45 EDT ---

Patch looks ok but it should be applied only in products where we actively issue:

+           "-smbios file=binary\n"
+           "                Load SMBIOS entry from binary file\n"
+           "-smbios
type=0[,vendor=str][,version=str][,date=str][,release=%%d.%%d]\n"
+           "                Specify SMBIOS type 0 fields\n"
+           "-smbios
type=1[,manufacturer=str][,product=str][,version=str][,serial=str]\n"
+           "              [,uuid=uuid][,sku=str][,family=str]\n"
+           "                Specify SMBIOS type 1 fields\n"

I've an hard time that mangling over bios dmidecode could ever be an appropriate way to send the host uuid information to any guest (perhaps it's me but I'm not fond of having deal with the bios in any way after boot, sure for certain things on real hardware we're forced to, as certain hardware only is accessible with acpi, but here we're not dealing with real hardware...).

Can't we use netcat or vmchannel? But perhaps I misunderstood what the uuid is about, I don't know RHN.

--- Additional comment from dlaor on 2009-05-10 04:43:26 EDT ---

(In reply to comment #10)
> Patch looks ok but it should be applied only in products where we actively
> issue:
> 
> +           "-smbios file=binary\n"
> +           "                Load SMBIOS entry from binary file\n"
> +           "-smbios
> type=0[,vendor=str][,version=str][,date=str][,release=%%d.%%d]\n"
> +           "                Specify SMBIOS type 0 fields\n"
> +           "-smbios
> type=1[,manufacturer=str][,product=str][,version=str][,serial=str]\n"
> +           "              [,uuid=uuid][,sku=str][,family=str]\n"
> +           "                Specify SMBIOS type 1 fields\n"
> 
> I've an hard time that mangling over bios dmidecode could ever be an
> appropriate way to send the host uuid information to any guest (perhaps it's me
> but I'm not fond of having deal with the bios in any way after boot, sure for
> certain things on real hardware we're forced to, as certain hardware only is
> accessible with acpi, but here we're not dealing with real hardware...).
> 
> Can't we use netcat or vmchannel? But perhaps I misunderstood what the uuid is
> about, I don't know RHN.  

Not doubt it is ugly but it this is the fastest way we can help RHN.
It is not that bad it is not accurate after migration.
Hope no anti virus or OS read and checksum this on run time.

--- Additional comment from aarcange on 2009-05-10 11:33:19 EDT ---

Ok just in case I re-sent the clean ACK to ML

--- Additional comment from ehabkost on 2009-05-11 14:50:08 EDT ---


Patches acked:
* Patch: qemu: Add support for SMBIOS command line options (Alex Williamson)
  (Message-Id: <20090430075427.GH5082>)
  - Acked-by: Markus Armbruster <armbru>
  - Acked-by: Zachary Amsden <zamsden>
  - Acked-by: Andrea Arcangeli <aarcange>

--- Additional comment from ykaul on 2009-05-12 08:45:20 EDT ---

Where do we want the host UUID to appear? In the SKU?

--- Additional comment from ykaul on 2009-05-13 06:00:04 EDT ---

I tried with KVM-83-43, and the following command line: 

-smbios type=0,vendor=RedHat,version=RHEV2.1,release=2.1 -smbios type=1,manufacturer="Red Hat",product=RHEV,version=2.1,serial=40E4001E-8C00-01B6-2356-00248C02BDCF,sku=SKU,uuid=111792f9-7a51-4915-1234-137222355537

(the serial is the hosts's UUID, btw). Is that good enough? (I really need to test it on Linux, though). I wonder where we want it - in the 'SKU' ? The 'Serial' field?