-
Notifications
You must be signed in to change notification settings - Fork 243
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider reading Ignition configs from SMBIOS OEM strings #656
Comments
Yes, I would still like to get enhancement to QEMU & libvirt to allow passing the OEM strings in via a file. If using libvirt XML there is a size limit on the overall XML document which would impact things, until we get ability to pass OEM strings via a file. |
BTW, I just tested the OEM strings XML syntax referenced in the docs, on F29 with libvirt 4.7.0 and qemu 3.0.0 and it was passed to QEMU, and visible in the guest with "dmidecode --oem-string 1" |
@berrange Whoops, you're right, I was missing the additional Even with file support for OEM strings, I was imagining that the Ignition config would still be embedded within the libvirt domain XML to avoid external references, and that as an implementation detail libvirt would pass that config to qemu as a file. Note that |
I'm undecided about integration in libvirt - we could have it inline in XML and pass it as a file to QEMU, but that could make the XML quite large. Maybe we should just allow both inline and external file reference in libvirt but then always pass as a file to QEMU. |
@berrange if you need some datapoints, the content of those tends to be quite large. ~250KiB is an average medium-complexity configuration. If this is likely to hit XML-inlining maximum size, passing file paths/descriptors around may be more reliable. This brings back the discussion on wiring this in security policies too. |
250 KB would definitely need to be stored in a separate file. |
digitalocean/go-smbios may get us most of what we need. |
SMBIOS is only available on x86 and ARM targets. @berrange, how would you suggest passing userdata to VMs on other architectures? |
Neither the current -fw_cfg or SMBIOS are portable across all possible QEMU architectures. OpenStack took approach of creating an extra cdrom drive and exporting that to the guest for passing arbitrary user data for cloud-init. Alternatively they also provide a live metadata network service via a well known IP addr (compatible with AWS) for cloud-init For an altogether different architecture portable solution you could also consider something like a virtio-serial or vsock communications channel. That has benefits that you can provide live updates for running guest, but is obviously a much greater level of complexity to support. |
@berrange At present, fw_cfg appears to be more portable than OEM strings. Might there be any interest in having QEMU provide a generic, cross-architecture userdata mechanism? Ignition intentionally doesn't support config drives because of their inherent race conditions, and AIUI the other options you mentioned require additional support code running outside QEMU. |
I'm going to close this out. We'll need to support non-x86, non-UEFI platforms, and it doesn't appear that the OEM strings mechanism will help with that. We do still need a better userdata mechanism than |
Hmm, using
Or maybe instead we add an |
My understanding is that |
We can bypass udev by just accessing it directly via |
Yeah, I don't see any difference to virtio-blk / virtio-net here - if you're willing to wait for virtio-serial devices to be probed on the PCI bus and exposed by the kernel in sysfs, then by implication it is fine for you todo the same for a virtio-blk device or a virtio-net device. They all share the same behaviour wrt probing & delayed exposure to userspace. The only things that won't have any delayed exposure are those based on a memory region, which covers fw_cfg, SMBIOS, and DIMMS/NVDIMMS |
Feature Request
Environment
QEMU
Desired Feature
QEMU developers would prefer that Ignition pass userdata via an SMBIOS OEM string rather than the
-fw_cfg
mechanism. See coreos/bugs#2083 (comment) and subsequent discussion. On QEMU, consider reading the Ignition config preferentially from an OEM string, falling back to-fw_cfg
for compatibility.Other Information
OEM strings have the following properties:
ignition:
, which is awkward but doable.ps
.Open questions:
Can we get libvirt to correctly pass through OEM strings?cc @berrange
The text was updated successfully, but these errors were encountered: