© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
0e1f616
(Get the code!)
As the name suggests, the "system-
The NoCloud data source is mis-using this field for receiving metadata for initializing cloud-init.
Admittedly there was not really a better alternative available from QEMU historically, if SMBIOS was the required comms channel. This is not true for the SMBIOS spec in general though. It has a specified a table called "OEM Strings" which has no semantics defined and thus intentionally available for passing arbitrary OEM defined data to the guest OS.
This is much better suited to usage by cloud-init, and with careful namespacing it is possible to use "OEM strings" for multiple purposes, not only cloud-init.
Thus I have implemented patches for QEMU to enable use of the "OEM strings" SMBIOS table
commit 2d6dcbf93fb01b4
Author: Daniel P. Berrange <email address hidden>
Date: Sat Oct 28 21:51:36 2017 +0100
smbios: support setting OEM strings table
The cloud-init program currently allows fetching of its data by repurposing of
the 'system' type 'serial' field. This is a clear abuse of the serial field that
would clash with other valid usage a virt management app might have for that
field.
Fortunately the SMBIOS defines an "OEM Strings" table whose puporse is to allow
exposing of arbitrary vendor specific strings to the operating system. This is
perfect for use with cloud-init, or as a way to pass arguments to OS installers
such as anaconda.
This patch makes it easier to support this with QEMU. e.g.
$QEMU -smbios type=11,
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
It is suggested that any app wanting to make use of this OEM strings capability
for accepting data from the host mgmt layer should use its name as a string
prefix. e.g. to expose OEM strings targetting both cloud init and anaconda in
parallel the mgmt app could set
$QEMU -smbios type=11,
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
Use of such string prefixes means the app won't have to care which string slot
its data appears in.
Signed-off-by: Daniel P. Berrange <email address hidden>
Reviewed-by: Michael S. Tsirkin <email address hidden>
Signed-off-by: Michael S. Tsirkin <email address hidden>
This will be in the QEMU 2.12 release due out end of April
And and equivalent patch to libvirt (released yesterday in 4.1.0) to allow it to be configured there and passed into QEMU
commit 68eed56b2d51e66
Author: Daniel P. Berrange <email address hidden>
Date: Sat Oct 28 14:56:51 2017 +0100
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
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 <email address hidden>
Signed-off-by: Daniel P. Berrange <email address hidden>
All that's missing now is a patch for cloud-init's NoCloud data source to make it look for data via the OEM strings table, in preference to the system table serial field.
Note in the above commits to QEMU/libvirt I illustrated an example of how to use an application specific prefix in the OEM strings entry to get nice namespacing.