Support userdata on QEMU s390x #825
Comments
|
Sorry for taking so long to reply to this.
This is separate from qemu. Qemu as a platform does not have any one way networking works.
We really dislike this. It's near impossible to differentiate between a disk that's slow to show up and a disk that will never show up. We do it where we have to (clouds where that's the only option) but we avoid it whenever possible. My knowledge of s390x is very limited right now, so unfortunately I don't have any counter-suggestions. |
|
My additional 2¢: if this is specifically for qemu s390x and not for (generically) metal s390x, then we'd like to identify a viable qemu-provided back-channel to use for this. EDIT: see coreos/mantle#1045 (comment) |
In pull request coreos/ignition-dracut#80 I've implemented something like this - mainly because we have to get rid of the hardcoded /boot dependency for openSUSE, which usually does not contain a separate boot partition. While doing so I made the partition containing the user config configurable - and the device could also be a cdrom device if desired. |
|
The temporary solution atm is to use guestfish. We would need a better way to deal with this. |
|
Potentially relevant here, there seems to be a I think this is a mechanism similar to what we are using on |
s390x doesn't support the qemu fw_cfg mechanism. Let's hack around this for now by having the fetcher on s390x just use the same one as OpenStack, i.e. config drives (and technically metadata server too, which will fail... again, this is a short-term hack). For background, see: coreos/coreos-assembler#1004 coreos/ignition-dracut#145 coreos#825
Feature Request
Environment
QEMU s390x
Desired Feature
Pass Ignition config file/string from host QEMU to FCOS guest.
Other Information
-fw_cfgandSMBIOS OEM stringare not supported.#656 (comment) suggests 2 approaches:
Related
coreos/ignition-dracut#87
#666
#656
The text was updated successfully, but these errors were encountered: