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

[Daniel P. Berrange]

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:
> > On Thu, Oct 21, 2010 at 09:52:51PM +0200, Daniel Veillard wrote:
> > >  The SMBIOS data are a standardized set of data structures available
> > > in the BIOS area of PCs. Those blocks of data describe things like
> > > BIOS version informations, machine vendor, model and identifiers,
> > > as well as various parts of the machine capability. On a linux
> > > machine running dmidecode allows to dump those informations.
> > > 
> > >   Spec available at the DMTF: http://dmtf.org/standards/smbios
> > > 
> > >   From a virtualization POV, it's mostly the first block describing
> > > the BIOS named "type 0" and the second block describing the machine
> > > named "type 1" which are of interest. Those data are usually accessed
> > > either from the OS or from management application, and being able to
> > > override the default setings may be needed for such management.
> > > 
> > >   The suggested XML description follows the logical structure of the
> > > data, one top smbios description, with one or more blocks, each
> > > containing the entries, the example below gives an idea:
> > > 
> > >   <smbios>
> > >     <table type="0">
> > >       <entry name="Vendor">QEmu/KVM</entry>
> > >       <entry name="Version">0.13</entry>
> > >     </table>
> > >     <table type="1">
> > >       <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>
> > >     </table>
> > >   </smbios>
> > 
> > I've never really been a fan of the idea of including SMBios
> > data in the XML because it is an x86 specific concept, which
> > only works with HVM guests & the type=1/2/3 is rather opaque
> > in meaning. 
> 
>   The semantic is well defined it's information available
> from the BIOS, c.f. the DMTF spec. The we know how to get it
> from a guest, and it's not dependant on the virtualization
> layer used, it may or may not support it, but at least
> the expectation are clear.
> 
> > 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

Regards,
Daniel
-- 
|: Red Hat, Engineering, London    -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :|
|: http://autobuild.org        -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|