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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list