[libvirt] [PATCH] 0/4 Add SMBIOS settings to domain definition

[Daniel Veillard]

On Fri, Oct 22, 2010 at 01:16:16PM +0100, Daniel P. Berrange wrote:
> On Fri, Oct 22, 2010 at 11:23:45AM +0200, Daniel Veillard wrote:
> > On Fri, Oct 22, 2010 at 09:28:48AM +0100, Daniel P. Berrange wrote:
[...]
> > > I can't help thinking that we should define a set of general
> > > metadata tags, and then have a internal mapping of those to 
> > > SMBIOS fields, in the same way that the <uuid> is automatically
> > > mapped to SMBIOS.
> > > 
> > > eg, define a set of metadata like this:
> > > 
> > >   <metadata>
> > >     <bios-vendor>SeaBIOS</bios-vendor>
> > >     <bios-version>0.13</bios-version>
> > >     <system-manufacturer>Fedora</system-manufacturer>
> > >     <system-product>KVM</system-product>
> > >     <system-version>0.8.2</system-version>
> > >     <system-uuid>c7a5fdbdedaf9455926ad65c16db1809</system-uuid>
> > >   </metadata>
> > 
> >   Okay, but what is the semantic of <system-product> for example ?
> > Does that mean SMBIOS type 1 Product Name or something else left
> > to the appreciation of the driver or of the user ?
> > 
> > > And for smbios just indicate what the source of the data is:
> > > 
> > >     <smbios mode="host|emulate"/>
> > > 
> > >   host - copy from host SMBIOS
> > >   emulate - generic emulator settings + metadata overrides
> > > 
> > > This would map better to what VMWare is letting you do, and let us expose
> > > the metadata through other non-SMBIOS data channels
> > 
> >   Your suggestion is far more flexible, but that comes with the
> > trouble that we have to define those metadata semantic, or we don't
> > define their semantic, and it may get messy in the long term.
> 
> How about a different variation on the theme.
> 
>    <sysinfo type="smbios">
>      <section name="bios">
>        <entry name="Vendor">QEmu/KVM</entry>
>        <entry name="Version">0.13</entry>
>      </section>
>      <section namee="platform">
>        <entry name="Manufacturer">Fedora</entry>
>        <entry name="Product">Virt-Manager</entry>
>        <entry name="Version">0.8.2-3.fc14</entry>
>        <entry name="UUID">c7a5fdbdedaf9455926ad65c16db1809</entry>
>      </section>
>    </sysinfo>
> 
> Where the valid section types, and entry names are defined according to
> the sysinfo type. So with type='smbios', the valid section/entries names
> would be 100% as per the SMBIOS spec.  If we add different sysinfo
> types, we can define appropriate sections/entries as per the spec for
> those types.  This keeps the strictly defined semantics, while avoiding
> a schema that is tied to smbios

  Okay, agreed, hierarchy may look a bit more complex as a result
but it allows to preserve both viewpoint.

  Also for the <smbios> element, should we make the mode a tristate:
    - emulate: do not try to override the default set by the hypervisor
      (if any)
    - host: get the values from the host (libvirtd may have to parse
      the dmidecode output as I don't see how to implement this for QEmu
      otherwise), the only useful mode for ESX driver
    - sysinfo: get the values from <sysinfo> section and pass them to
      the hypervisor.
Also I'm wondering if we should treat <smbios> as a device or keep it
as a top level element along <cpu> etc.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/