| 2018-03-05 18:33:18 |
Daniel Berrange |
bug |
|
|
added bug |
| 2018-03-05 18:38:44 |
Daniel Berrange |
attachment added |
|
Proof of concept impl using OEM strings https://bugs.launchpad.net/cloud-init/+bug/1753558/+attachment/5070139/+files/0001-NoCloud-support-seed-of-nocloud-from-SMBIOS-OEM-stri.patch |
|
| 2018-03-06 08:57:46 |
Scott Moser |
cloud-init: status |
New |
Confirmed |
|
| 2018-03-06 08:57:53 |
Scott Moser |
cloud-init: importance |
Undecided |
Medium |
|
| 2020-05-20 17:04:08 |
Scott Moser |
description |
As the name suggests, the "system-serial-number" field in SMBIOS is intended for exposing a serial number identifying the hardware, to the operating 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 2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
Author: Daniel P. Berrange <berrange@redhat.com>
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,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
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,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
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 <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
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 68eed56b2d51e66bb540062fe09f5ffd44e99f6e
Author: Daniel P. Berrange <berrange@redhat.com>
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
<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>
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. |
As the name suggests, the "system-serial-number" field in SMBIOS is intended for exposing a serial number identifying the hardware, to the operating 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 2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
Author: Daniel P. Berrange <berrange@redhat.com>
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,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
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,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
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 <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
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 68eed56b2d51e66bb540062fe09f5ffd44e99f6e
Author: Daniel P. Berrange <berrange@redhat.com>
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
<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>
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.
Related bugs:
* bug 1879294: Support fw_cfg data source
* bug 1753558: NoCloud should use "OEM Strings" instead of
system-serial-number |
|
| 2020-05-20 17:09:56 |
Scott Moser |
description |
As the name suggests, the "system-serial-number" field in SMBIOS is intended for exposing a serial number identifying the hardware, to the operating 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 2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
Author: Daniel P. Berrange <berrange@redhat.com>
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,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
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,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
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 <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
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 68eed56b2d51e66bb540062fe09f5ffd44e99f6e
Author: Daniel P. Berrange <berrange@redhat.com>
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
<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>
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.
Related bugs:
* bug 1879294: Support fw_cfg data source
* bug 1753558: NoCloud should use "OEM Strings" instead of
system-serial-number |
As the name suggests, the "system-serial-number" field in SMBIOS is intended for exposing a serial number identifying the hardware, to the operating 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 2d6dcbf93fb01b4a7f45a93d276d4d74b16392dd
Author: Daniel P. Berrange <berrange@redhat.com>
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,value=Hello,value=World,value=Tricky,,value=test
Which results in the guest seeing dmidecode data
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: Hello
String 2: World
String 3: Tricky,value=test
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,value=cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/,\
value=anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
which would appear as
Handle 0x0E00, DMI type 11, 5 bytes
OEM Strings
String 1: cloud-init:ds=nocloud-net;s=http://10.10.0.1:8000/
String 2: anaconda:method=http://dl.fedoraproject.org/pub/fedora/linux/releases/25/x86_64/os
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 <berrange@redhat.com>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
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 68eed56b2d51e66bb540062fe09f5ffd44e99f6e
Author: Daniel P. Berrange <berrange@redhat.com>
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
<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>
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.
Related bugs:
* bug 1879294: Support fw_cfg data source
* bug 1753558: NoCloud should use "OEM Strings" instead of
system-serial-number
* bug 1691772: provide a way to seed NoCloud from network without image modification. |
|
| 2023-05-11 11:55:00 |
James Falcon |
bug watch added |
|
https://github.com/canonical/cloud-init/issues/3133 |
|
| 2023-05-11 11:55:01 |
James Falcon |
cloud-init: status |
Confirmed |
Expired |
|
