Commit Graph

8 Commits

Author SHA1 Message Date
Zhuang Yanying
c8fec25692 conf: Add support for setting Chassis SMBIOS data fields
This type of information defines attributes of a system
chassis, such as SMBIOS Chassis Asset Tag.

access inside VM (for example)
Linux:   /sys/class/dmi/id/chassis_asset_tag.
Windows: (Get-WmiObject Win32_SystemEnclosure).SMBIOSAssetTag
          wirhin Windows PowerShell.

As an example, add the following to the guest XML

    <chassis>
      <entry name='manufacturer'>Dell Inc.</entry>
      <entry name='version'>2.12</entry>
      <entry name='serial'>65X0XF2</entry>
      <entry name='asset'>40000101</entry>
      <entry name='sku'>Type3Sku1</entry>
    </chassis>

Signed-off-by: Zhuang Yanying <ann.zhuangyanying@huawei.com>
Reviewed-by: John Ferlan <jferlan@redhat.com>
2018-02-17 07:36:46 -05:00
Daniel P. Berrange
68eed56b2d conf: add support for setting OEM strings SMBIOS data fields
The OEM strings table in SMBIOS allows the vendor to pass arbitrary
strings into the guest OS. This can be used as a way to pass data to an
application like cloud-init, or potentially as an alternative to the
kernel command line for OS installers where you can't modify the install
ISO image to change the kernel args.

As an example, consider if cloud-init and anaconda supported OEM strings
you could use something like

    <oemStrings>
      <entry>cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/</entry>
      <entry>anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os</entry>
    </oemStrings>

use of a application specific prefix as illustrated above is
recommended, but not mandated, so that an app can reliably identify
which of the many OEM strings are targetted at it.

Reviewed-by: John Ferlan <jferlan@redhat.com>
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
2018-01-25 14:48:56 +00:00
Michal Privoznik
a9a27e602c virSysinfo: Introduce SMBIOS type 2 support
https://bugzilla.redhat.com/show_bug.cgi?id=1220527

This type of information defines attributes of a system
baseboard. With one exception: board type is yet not implemented
in qemu so it's not introduced here either.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-06-18 10:10:26 +02:00
Michal Privoznik
0b92974c15 virSysinfoDef: Exempt SYSTEM variables
Move all the system_* fields into a separate struct. Not only this
simplifies the code a bit it also helps us to identify whether BIOS
info is present. We don't have to check all the four variables for
being not-NULL, but we can just check the pointer to the struct.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-06-12 10:42:39 +02:00
Michal Privoznik
3f9cae18fe virSysinfoDef: Exempt BIOS variables
Move all the bios_* fields into a separate struct. Not only this
simplifies the code a bit it also helps us to identify whether BIOS
info is present. We don't have to check all the four variables for
being not-NULL, but we can just check the pointer to the struct.

Signed-off-by: Michal Privoznik <mprivozn@redhat.com>
2015-06-12 10:42:34 +02:00
Julio Faracco
1b14c449b8 util: use typedefs for enums in "src/util/" directory
In "src/util/" there are many enumeration (enum) declarations.
Sometimes, it's better using a typedef for variable types,
function types and other usages. Other enumeration will be
changed to typedef's in the future.

Signed-off-by: Julio Faracco <jcfaracco@gmail.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
2014-05-05 14:30:01 -06:00
Daniel P. Berrange
44f6ae27fe Rename util.{c,h} to virutil.{c,h} 2012-12-21 11:19:49 +00:00
Daniel P. Berrange
88ba722c12 Rename sysinfo.{c,h} to virsysinfo.{c,h} 2012-12-21 11:19:48 +00:00