-
Notifications
You must be signed in to change notification settings - Fork 553
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
Add VM-based runtime configuration details. #405
Changes from all commits
72e8060
177157d
89ed60a
fe42b99
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
# Virtual-machine-specific Configuration | ||
|
||
Virtual-machine-based runtimes require additional configuration to that specified in the [default spec configuration](config.md). | ||
|
||
This optional configuration is specified in a "VM" object: | ||
|
||
* **`imagePath`** (string, required) host path to file that represents the root filesystem for the virtual machine. | ||
* **`kernel`** (object, required) specifies details of the kernel to boot the virtual machine with. | ||
|
||
Note that `imagePath` refers to a path on the host (outside of the virtual machine). | ||
This field is distinct from the **`path`** field in the [Root Configuration](config.md#Root-Configuration) section since in the context of a virtual-machine-based runtime: | ||
|
||
* **`imagePath`** will represent the host path to the root filesystem for the virtual machine. | ||
* The container root filesystem specified by **`path`** from the [Root Configuration](config.md#Root-Configuration) section will be mounted inside the virtual machine at a location chosen by the virtual-machine-based runtime. | ||
|
||
The virtual-machine-based runtime will use these two path fields to arrange for the **`path`** from the [Root Configuration](config.md#Root-Configuration) section to be presented to the process to run as the root filesystem. | ||
|
||
## Kernel | ||
|
||
Used by virtual-machine-based runtimes only. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Maybe you should specify that these are all host paths (or if they could be other paths, you could make it if they're absolute paths then they're host paths). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Fixed. |
||
|
||
* **`path`** (string, required) specifies the host path to the kernel used to boot the virtual machine. | ||
* **`parameters`** (string, optional) specifies a space-separated list of parameters to pass to the kernel. | ||
* **`initrd`** (string, optional) specifies the host path to an initial ramdisk to be used by the virtual machine. | ||
|
||
## Example of a fully-populated `VM` object | ||
|
||
```json | ||
"vm": { | ||
"imagePath": "path/to/rootfs.img", | ||
"kernel": { | ||
"path": "path/to/vmlinuz", | ||
"parameters": "foo=bar hello world", | ||
"initrd": "path/to/initrd.img" | ||
}, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Surely these examples should use absolute paths? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What, no bring-your-own-kernel? ;) I think the semantics of relative paths can be made clear (relative to the bundle, to match the pattern set by There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @cyphar - thanks for the suggestion. I personally am very much in favour of absolute paths (only), but this has been discussed previously (see old comments above) and this example was adjusted accordingly to show a non-absolute path. |
||
} | ||
``` |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -191,6 +191,9 @@ | |
} | ||
} | ||
}, | ||
"vm": { | ||
"$ref": "schema-vm.json#/vm" | ||
}, | ||
"linux": { | ||
"$ref": "config-linux.json#/linux" | ||
}, | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,43 @@ | ||
{ | ||
"vm": { | ||
"description": "configuration for virtual-machine-based runtimes", | ||
"id": "https://opencontainers.org/schema/bundle/vm", | ||
"type": "object", | ||
"required" : [ | ||
"imagePath", | ||
"kernel" | ||
], | ||
"properties": { | ||
"imagePath": { | ||
"description": "host path to rootfs image on host system which is used for VM-based runtimes", | ||
"id": "https://opencontainers.org/schema/bundle/vm/imagePath", | ||
"type": "string" | ||
}, | ||
"kernel": { | ||
"description": "kernel config used by VM-based runtimes", | ||
"id": "https://opencontainers.org/schema/bundle/vm/kernel", | ||
"type": "object", | ||
"required": [ | ||
"path" | ||
], | ||
"properties": { | ||
"path": { | ||
"id": "https://opencontainers.org/schema/bundle/vm/kernel/path", | ||
"description": "host path to kernel image", | ||
"type": "string" | ||
}, | ||
"parameters": { | ||
"description": "space-separated list of kernel parameters", | ||
"id": "https://opencontainers.org/schema/bundle/vm/kernel/parameters", | ||
"type": "string" | ||
}, | ||
"initrd": { | ||
"description": "host path to initial ramdisk image", | ||
"id": "https://opencontainers.org/schema/bundle/vm/kernel/initrd", | ||
"type": "string" | ||
} | ||
} | ||
} | ||
} | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This might make sense as a structure, rather than just a path, to allow different kinds of images in the future.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @stevvooe - what members were you thinking would be in this structure initially aside from
path
? We could introduce animageType
possibly, but then the runtime could detect the type itself potentially from the file header. There isn't akernelType
member currently although arguably there could be, but the hypervisor we use detects the kernel type at runtime.Also, if type members get added, presumably the behaviour would need to be documented should the type specified not match that detected by the runtime. But that implies the runtime would need to validate the type itself which makes me wonder if we anything beyond
imagePath
. Maybe such type members could be optional and default toauto-detect
meaning the runtime is responsible for determining if it is a supported type?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jodh-intel I am not quite sure here. This isn't exactly the right layer to be relying on autodetect. That seems like something that would belong at a higher-level (ie whatever creates this file). Containers are mostly different in that the rootfs is either pre-expanded or a few host mounts away.
With an image file, its quite different. Does this image file get mounted? How are the parameters for that mount resolved? Is
kernel.path
relative to the image root or to the host root? What happens to the regular containerrootfs
? Does it get replaced by this image?