-
Notifications
You must be signed in to change notification settings - Fork 59
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
Platform Request: Microsoft Hyper-V #1411
Comments
Previous investigation done by the CoreOS team in 2020 - https://issues.redhat.com/browse/COS-842 |
Thanks for filing this. coreos/ignition#1538 tracks the Ignition portion.
Re-emphasizing, for safety, that this needs to be new code for license compatibility reasons.
Does DHCP actually always deliver this? If not (e.g. if Hyper-V doesn't control the DHCP server) we might need to teach Afterburn to read the hostname key. |
Our Hyper-V docs should include a PowerShell script that takes a VM identifier and an Ignition config, chunks the config into appropriately-sized pieces, and creates the KVP keys. |
Add hyperV support to cosa including a buildextend command to create vhdx images. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
Add hyperV support to cosa including a buildextend command to create vhdx images. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
This PR adds initial support for the Microsoft HyperV platform. It uses HyperV and MS WMI to read key/value pairs as provided by the Windows host. Because the size allocation of the value is quite small, the ignition values will likely be split into at least 2 and more like more parts which must be read and reassembled in ignition. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
This PR adds initial support for the Microsoft HyperV platform. It uses HyperV and MS WMI to read key/value pairs as provided by the Windows host. Because the size allocation of the value is quite small, the ignition values will likely be split into at least 2 and more like more parts which must be read and reassembled in ignition. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
Add hyperV support to cosa including a buildextend command to create vhdx/hyperv images. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
This PR adds initial support for the Microsoft HyperV platform. It uses HyperV and MS WMI to read key/value pairs as provided by the Windows host. Because the size allocation of the value is quite small, the ignition values will likely be split into at least 2 and more like more parts which must be read and reassembled in ignition. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
This PR adds initial support for the Microsoft HyperV platform. It uses HyperV and MS WMI to read key/value pairs as provided by the Windows host. Because the size allocation of the value is quite small, the ignition values will likely be split into at least 2 and more like more parts which must be read and reassembled in ignition. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
This PR adds initial support for the Microsoft HyperV platform. It uses HyperV and MS WMI to read key/value pairs as provided by the Windows host. Because the size allocation of the value is quite small, the ignition values will likely be split into at least 2 and more like more parts which must be read and reassembled in ignition. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
Implementation checklist in #1424. |
Add a buildextend-hyperv command that creates a `hyperv` image in VHDX format. Supports coreos/fedora-coreos-tracker#1411. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
Add a buildextend-hyperv command that creates a `hyperv` image in VHDX format. Supports coreos/fedora-coreos-tracker#1411.
@baude pointed out that Windows can't decompress |
Add a buildextend-hyperv command that creates a `hyperv` image in VHDX format. Supports coreos/fedora-coreos-tracker#1411.
This PR adds initial support for the Microsoft HyperV platform. It uses HyperV and MS WMI to read key/value pairs as provided by the Windows host. Because the size allocation of the value is quite small, the ignition values will likely be split into at least 2 and more like more parts which must be read and reassembled in ignition. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
buildextend --compress supports gzip as an alternate compression over xz using a key called "gzip" where the value is a bool. This is now refactored to a key called "compression" with a value of "gzip", "skip", or "zip" (see below). The "skip-compression" key is no longer applicable. HyperV images which are used on Windows need to be compressed with zip because xz and gzip are not supported natively. Added zip support to buildextend and set the hyperv platform compression to "zip". Supports: * coreos/fedora-coreos-tracker#1411 * coreos/fedora-coreos-tracker#1421 Signed-off-by: Brent Baude <[email protected]>
Supports: * coreos/fedora-coreos-tracker#1411 * coreos/fedora-coreos-tracker#1421 Signed-off-by: Brent Baude <[email protected]>
Supports: * coreos/fedora-coreos-tracker#1411 * coreos/fedora-coreos-tracker#1421 Signed-off-by: Brent Baude <[email protected]>
This PR adds initial support for the Microsoft HyperV platform. It uses HyperV and MS WMI to read key/value pairs as provided by the Windows host. Because the size allocation of the value is quite small, the ignition values will likely be split into at least 2 and more like more parts which must be read and reassembled in ignition. Supports coreos/fedora-coreos-tracker#1411 Signed-off-by: Brent Baude <[email protected]>
This PR adds initial support for the Microsoft HyperV platform. It uses HyperV and MS WMI to read key/value pairs as provided by the Windows host. Because the size allocation of the value is quite small, the ignition values will likely be split into at least 2 and more like more parts which must be read and reassembled in ignition. Supports: * coreos/fedora-coreos-tracker#1411 * coreos/fedora-coreos-tracker#1424 Signed-off-by: Brent Baude <[email protected]>
This PR adds initial support for the Microsoft HyperV platform. It uses HyperV and MS WMI to read key/value pairs as provided by the Windows host. Because the size allocation of the value is quite small, the ignition values will likely be split into at least 2 and more like more parts which must be read and reassembled in ignition. Supports: * coreos/fedora-coreos-tracker#1411 * coreos/fedora-coreos-tracker#1424 Signed-off-by: Brent Baude <[email protected]>
Read the Ignition config from the Hyper-V Data Exchange Service ("KVP"), which can be configured on the host via WMI. KVP on Linux is normally handled by a combination of a kernel module (hv_utils) and a daemon shipped with the kernel source (hv_kvp_daemon). The latter writes world-readable files to /var/lib/hyperv; these contain an array of binary structs. The host-guest protocol has the guest OS as the passive peer; hv_kvp_daemon connects and is sent all the host's key-value pairs. We don't want to require hv_kvp_daemon as a dependency, so we use a pure Go reimplementation (libhvee) that supports just enough of the protocol to receive the KVPs. However, if we disconnect and then hv_kvp_daemon reconnects later, the host won't re-send the KVPs, so we also need to save them to /var/lib/hyperv in the same format used by the daemon. Unlike the daemon, we set the files to mode 600, since the Ignition config is potentially sensitive; the daemon does not change the permissions of existing files. Small configs can be stored in the `ignition.config` KVP. However, individual values have severe length limitations (~1 KiB of UTF-8), so we also support concatenating `ignition.config.0`, `ignition.config.1`, etc. to form a larger config. See also: coreos/fedora-coreos-tracker#1411 coreos/fedora-coreos-tracker#1424 Almost all of this work was done by Brent Baude; I just added the final polish. Thanks Brent! Co-authored-by: Brent Baude <[email protected]>
Supports: * coreos/fedora-coreos-tracker#1411 * coreos/fedora-coreos-tracker#1424 Co-authored-by: Brent Baude <[email protected]>
Read the Ignition config from the Hyper-V Data Exchange Service ("KVP"), which can be configured on the host via WMI. KVP on Linux is normally handled by a combination of a kernel module (hv_utils) and a daemon shipped with the kernel source (hv_kvp_daemon). The latter writes world-readable files to /var/lib/hyperv; these contain an array of binary structs. The host-guest protocol has the guest OS as the passive peer; hv_kvp_daemon connects and is sent all the host's key-value pairs. We don't want to require hv_kvp_daemon as a dependency, so we use a pure Go reimplementation (libhvee) that supports just enough of the protocol to receive the KVPs. However, if we disconnect and then hv_kvp_daemon reconnects later, the host won't re-send the KVPs, so we also need to save them to /var/lib/hyperv in the same format used by the daemon. Unlike the daemon, we set the files to mode 600, since the Ignition config is potentially sensitive; the daemon does not change the permissions of existing files. Small configs can be stored in the `ignition.config` KVP. However, individual values have severe length limitations (~1 KiB of UTF-8), so we also support concatenating `ignition.config.0`, `ignition.config.1`, etc. to form a larger config. See also: coreos/fedora-coreos-tracker#1411 coreos/fedora-coreos-tracker#1424 Almost all of this work was done by Brent Baude; I just added the final polish. Thanks Brent! Co-authored-by: Brent Baude <[email protected]>
I've looked through the Hyper-V Manager and Virtual Machine Connection UIs in Windows Server 2024, and serial port setup is not surfaced anywhere. I think it's safe to stick with graphical console only for now. |
Add example metadata for new platform support of hyperv. This supports: * coreos#1411 * coreos#1424
Add example metadata for hyperv platform. This supports: * coreos#1411 * coreos#1424 Co-authored-by: Brent Baude <[email protected]>
Read the Ignition config from the Hyper-V Data Exchange Service ("KVP"), which can be configured on the host via WMI. KVP on Linux is normally handled by a combination of a kernel module (hv_utils) and a daemon shipped with the kernel source (hv_kvp_daemon). The latter writes world-readable files to /var/lib/hyperv; these contain an array of binary structs. The host-guest protocol has the guest OS as the passive peer; hv_kvp_daemon connects and is sent all the host's key-value pairs. We don't want to require hv_kvp_daemon as a dependency, so we use a pure Go reimplementation (libhvee) that supports just enough of the protocol to receive the KVPs. However, if we disconnect and then hv_kvp_daemon reconnects later, the host won't re-send the KVPs, so we also need to save them to /var/lib/hyperv in the same format used by the daemon. Unlike the daemon, we set the files to mode 600, since the Ignition config is potentially sensitive; the daemon does not change the permissions of existing files. Small configs can be stored in the `ignition.config` KVP. However, individual values have severe length limitations (~1 KiB of UTF-8), so we also support concatenating `ignition.config.0`, `ignition.config.1`, etc. to form a larger config. See also: coreos/fedora-coreos-tracker#1411 coreos/fedora-coreos-tracker#1424 Almost all of this work was done by Brent Baude; I just added the final polish. Thanks Brent! Co-authored-by: Brent Baude <[email protected]>
The fix for this went into |
The fix for this went into |
The fix for this went into |
Please see our docs for more information on how to use this new image! |
Follow-up to coreos/fedora-coreos-tracker#1411 Signed-off-by: Jason T. Greene <[email protected]>
Follow-up to coreos/fedora-coreos-tracker#1411 Signed-off-by: Jason T. Greene <[email protected]>
Is it possible we can add the Hyper-V specific tools to the builds? For example, |
Ususally we don't ship agents. see #12 If you'd like to carry this conversation further please open a new issue. |
Follow-up to coreos/fedora-coreos-tracker#1411 Signed-off-by: Jason T. Greene <[email protected]>
Why is the platform important? Who uses it?
Microsoft HyperV is a widely known and adopted virtualization platform for Windows. The Podman team would also like to being supporting HyperV with their
podman machine
function which uses FCOS as its base OS. I understand separately FCOS would like to support HyperV as well presumably due to user demand.What is the official name of the platform? Is there a short name that's commonly used in client API implementations?
Microsoft HyperV
How can the OS retrieve instance userdata? What happens if no userdata is provided?
HyperV implements a key-value-pair (KVP) through its hypervisor using Windows Management Implementation (WMI).
On the host side, the injection occurs by setting values in a given registry. The KVP does have limitations; the key is limited to 512 bytes and the value 2048 bytes. Because this is Windows UTF halves those values to 256 and 1024.
On the Linux guest, the KVPs are shared by WMI and are written to the Linux kernel. Using code from the already existing hypervkvpd (daemon), we can extract the information we need. Because of the 1K value limit, the values will need to be split up on the host and re-assembled on the guest.
Does the platform provide a way to configure SSH keys for the instance? How can the OS retrieve them? What happens if none are provided?
I do not know. I want to use ignition for this.
How can the OS retrieve network configuration? Is DHCP sufficient, or is there some other network-accessible metadata service?
DHCP is sufficient
In particular, how can the OS retrieve the system hostname?
The host hostname is also provided as a KVP automatically. Otherwise the expectation is that DHCP delivers this.
Does the platform require the OS to have a specific console configuration?
I do not believe so, but we should clarify what exactly this question is asking ...
Is there a mechanism for the OS to report to the platform that it has successfully booted? Is the mechanism required?
It could be done if really needed through KVPs as well but it would require code on the host looking for it. The mechanism is not required.
Does the platform have an agent that runs inside the instance? Is it required? What does it do? What language is it implemented in, and where is the source code repository?
There are such things. Early analysis suggests we do not need it and therefore is optional.
How are VM images uploaded to the platform and published to other users? Is there an API? What disk image format is expected?
the disk format is vhd/vhdx. the long term expectation is that these images would be produced upstream
Are there any other platform quirks we should know about?
ah! it's windows!
The text was updated successfully, but these errors were encountered: