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 ?
It is simply a NULL terminated string for the system product name. > > 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. It is worth the extra work, because it gives us a representation of data which is hypervisor-agnostic, which is the primary goal of our XML format. If I want to specify a 'product name' for the LXC containers, I don't want to have to use different XML for that, compared to setting 'product name' for KVM. With the exception of the UUID field, these are all simply NULL terminated free form strings, so defining a mapping to SMBIOS fields is pretty straightforward. 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@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
