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

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