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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list