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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/