providers/virtualbox: read config from /Ignition/Config guest property#1269
providers/virtualbox: read config from /Ignition/Config guest property#1269bgilbert merged 1 commit intocoreos:mainfrom bgilbert:virtualbox
/Ignition/Config guest property#1269Conversation
| msg->parm_count = 4; | ||
|
|
||
| // init arguments | ||
| char ch; |
There was a problem hiding this comment.
This seems not really used by us and mostly innocent, but I think it won't hurt zero-initializing it anyway.
There was a problem hiding this comment.
I hesitate to initialize it, only because that might imply that the value is used. We don't similarly zero-fill the real buffer after allocating it.
|
Nice! |
I'm interested in thoughts on that topic. It looks like the pattern was originally introduced in #191 for compatibility with coreos-cloudinit, and I'm not sure if we should propagate it. Both the FCOS and OCP docs recommend As to compression support, there was a previous discussion in #1100. I still tend to think users should handle userdata size limits by moving data into a merged config rather than relying on compression, but I wouldn't say there's a universal consensus there. I'm not aware of existing users of |
|
Rebased onto #1271. |
|
Fair points. To be clear, I'm not arguing for multi-format auto-detection like in #1100, but for (optional) explicit encoding declaration. For Overall I'm fine with this without encoding support upfront (or maybe ever), as long as we have some room to add it later if needed. |
|
Linking coreos/fedora-coreos-tracker#144. This is interesting and could potentially enable Vagrant support! |
Yup, understood.
When injecting configs using
Yes, that's supported. The namespace is just key-value pairs. Pursuant to that, I've added code to fail if |
VirtualBox supports "guest properties", which are persistent UTF-8
key-value pairs accessible from both the host and guest. Property values
were originally limited to 128 bytes, and the VirtualBox codebase still
contains vestiges of that limit, such as fixed-size buffers in some client
code. The limit is no longer enforced by the VirtualBox core; it seems to
have been removed in r21629 in 2009.
Read Ignition configs from an /Ignition/Config guest property by talking
directly to the upstream vboxguest kernel module via /dev/vboxguest.
Ignition configs can be attached to a VM with something like this command:
VBoxManage guestproperty set vm-name /Ignition/Config "$(cat config.ign)"
When using this approach (rather than the VirtualBox XPCOM API), configs
are subject to these limits:
Linux: 128 KiB (MAX_ARG_STRLEN)
macOS: 256 KiB (ARG_MAX)
Windows bash: 32 KiB (UNICODE_STRING.MaximumLength)
Windows cmd.exe or PowerShell: 8 KiB
(The limits are actually slightly lower for various reasons.)
For forward compatibility, check that the /Ignition/Config/Encoding
property is missing or empty. In the future we might want to support
alternate encodings (e.g. gzip+base64), similar to the VMware provider.
Drop support for the old magic partition GUID. It was implemented for
the old Container Linux Vagrant provider, which was never widely deployed.
It isn't practical for hand-crafting a config drive, since it requires
creating a disk image with a partition table and then inserting the config
into a partition, and I'm not aware of any active users in the wild.
Fixes #629.
|
After playing around on windows, I found that the maximum size limit for a command is I tested this on WSL and git bash with |
VirtualBox supports "guest properties", which are persistent UTF-8 key-value pairs accessible from both the host and guest. Property values were originally limited to 128 bytes, and the VirtualBox codebase still contains vestiges of that limit, such as fixed-size buffers in some client code. The limit is no longer enforced by the VirtualBox core; it seems to have been removed in r21629 in 2009.
Read Ignition configs from an
/Ignition/Configguest property by talking directly to the upstream vboxguest kernel module via/dev/vboxguest. Ignition configs can be attached to a VM with something like this command:When using this approach (rather than the VirtualBox XPCOM API), configs are subject to these limits:
MAX_ARG_STRLENARG_MAXCreateProcessUNICODE_STRING.MaximumLength(The limits are actually slightly lower for various reasons.)
For forward compatibility, check that the
/Ignition/Config/Encodingproperty is missing or empty. In the future we might want to support alternate encodings (e.g.gzip+base64), similar to the VMware provider.Drop support for the old magic partition GUID. It was implemented for the old Container Linux Vagrant provider, which was never widely deployed. It isn't practical for hand-crafting a config drive, since it requires creating a disk image with a partition table and then inserting the config into a partition, and I'm not aware of any active users in the wild.
Fixes #629.