Component
EFI
What problem are you facing?
I'd like to be able to assign meaningful hostnames, pass SSH authorized keys and other initial data through to VM appliances without having to set up each appliance manually. One example would be multiple clones of the same VM template, or clones of an imported OVA.
How can we fix this?
Linux guests that rely on systemd scan DMI Type 11 strings and look for designated key-value, like anaconda:method=http://example.org/oracle/linux/os or init:system.hostname=box.example.org.
The convention is described in the following man page.
This applies to many popular GNU/Linux-based guest operating systems, including Fedora Server and Debian, and is implemented in QEMU hosts. In addition, the mechanism is generic enough it can be adopted by non-Linux guests too.
I suggest to make it possible to set those strings in the VM settings. E. g., to add a namespace:key=value string to the guest's DMI Type 11 block:
VBoxManage setextradata "$vm_name" VBoxInternal/Devices/pcbios/0/Config/DmiOEMString0 "string:namespace:key=value"
Not sure how to represent a sequence of strings in the extradata config space, though. A straightforward approach would be to store numbered keys (e. g. DmiOEMString0, DmiOEMString1 and so on), and the total count of those keys in e. g. DmiOEMStrings. This is similar to CustomVideoModes.
We alternatively can go for a single extradata key, with all the DMI strings sequentially joined together with some separator character.
What alternatives or workarounds exist?
Currently we opted to embed this information in the "board vendor" and "SKU number" DMI type 2 entries:
VBoxManage setextradata "$vm_name" VBoxInternal/Devices/pcbios/0/Config/DmiSystemVendor "$desired_hostname"
VBoxManage setextradata "$vm_name" VBoxInternal/Devices/pcbios/0/Config/DmiSystemSKU "$user_data"
Anything else we should know?
I've set the "Component" field to "EFI", since the bulk of the implementation would likely be local to these 3 files:
src/VBox/Devices/EFI/DevEFI.cpp
src/VBox/Devices/PC/DevFwCommon.cpp
src/VBox/Devices/PC/DevPcBios.cpp
If that's wrong, please reassign. :)
Component
EFI
What problem are you facing?
I'd like to be able to assign meaningful hostnames, pass SSH authorized keys and other initial data through to VM appliances without having to set up each appliance manually. One example would be multiple clones of the same VM template, or clones of an imported OVA.
How can we fix this?
Linux guests that rely on systemd scan DMI Type 11 strings and look for designated key-value, like
anaconda:method=http://example.org/oracle/linux/osorinit:system.hostname=box.example.org.The convention is described in the following man page.
This applies to many popular GNU/Linux-based guest operating systems, including Fedora Server and Debian, and is implemented in QEMU hosts. In addition, the mechanism is generic enough it can be adopted by non-Linux guests too.
I suggest to make it possible to set those strings in the VM settings. E. g., to add a
namespace:key=valuestring to the guest's DMI Type 11 block:Not sure how to represent a sequence of strings in the extradata config space, though. A straightforward approach would be to store numbered keys (e. g.
DmiOEMString0,DmiOEMString1and so on), and the total count of those keys in e. g.DmiOEMStrings. This is similar toCustomVideoModes.We alternatively can go for a single extradata key, with all the DMI strings sequentially joined together with some separator character.
What alternatives or workarounds exist?
Currently we opted to embed this information in the "board vendor" and "SKU number" DMI type 2 entries:
Anything else we should know?
I've set the "Component" field to "EFI", since the bulk of the implementation would likely be local to these 3 files:
If that's wrong, please reassign. :)