Okd: Missing hyperv-daemon package for code-ready container deployment

[daFritz84]

Describe the bug
When running the okd image in an Hyper-V Environment, the IP address of the running VM does not get reported to the Hypervisor. I.e. using the code ready container environment: The system is rendered unusable as crc freezes during startup waiting indefinetely for the IP address.

See also this CRC Issue

Version
4.5.0-0.okd-2020-10-15-235428

How reproducible
Using crc:

1. .\crc.exe setup
2. .\crc.exe start -p .\pull-secret.txt

``bash PS E:\crc> .\crc.exe start -p .\pull-secret.txt WARN A new version (1.18.0) has been published on https://cloud.redhat.com/openshift/install/crc/installer-provisioned INFO Checking if oc binary is cached INFO Checking if podman remote binary is cached INFO Checking if goodhosts binary is cached INFO Checking minimum RAM requirements INFO Checking if running as normal user INFO Checking Windows 10 release INFO Checking Windows edition INFO Checking if Hyper-V is installed and operational INFO Checking if user is a member of the Hyper-V Administrators group INFO Checking if Hyper-V service is enabled INFO Checking if the Hyper-V virtual switch exist INFO Found Virtual Switch to use: Default Switch INFO Extracting bundle: crc_hyperv_4.5.0-0.okd-2020-10-15-235428.crcbundle ... crc.vhdx: 11.27 GiB / 11.27 GiB [-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------] 100.00% INFO Checking size of the disk image E:\Users\sseifried\.crc\cache\crc_hyperv_4.5.0-0.okd-2020-10-15-235428\crc.vhdx ... INFO Creating CodeReady Containers VM for OpenShift 4.5.0-0.okd-2020-10-15-235428... ```` Nowcrc` waits for the IP address.

Log bundle
Not applicable

Workaround
Install hyperv-daemons package
See also this CRC Issue

[cgruver]

@vrutkovs @dustymabe Do we need to include hyperv-daemons in the base FCOS image? Or, should we install it during creation of a single node cluster on HyperV?

[vrutkovs]

Install hyperv-daemons package

If its shipped in Fedora we could include it, yeah.

OKD 4.6 is able to install arbitrary packages - via OS extensions mechanism. You may have to enable necessary Fedora repos (these are disabled by default).

So if the list of additional packages (including dependencies) is not too large and the daemon is not too resource hungry we could include it by default

[gbraad]

This does sound concerning to me; as this means the snc scripts might have been used but modified and refactored to a point where the hyper-v modifications disappeared? I hope @cgruver can address this and move to a way that the snc scripts get configured to perform an OKD-based install. Ref

[gbraad]

we could include it by default

To stick to the SNC scripts I would be 'wise' to only have this modificatrion happen (include by installing) for only the hyper-v images.

Or, should we install it during creation of a single node cluster on HyperV?

Yes... This is how CRC deals with this.

# Download the hyperV daemons and libvarlink-util dependency on host
mkdir $1/packages
sudo yum install -y --downloadonly --downloaddir $1/packages hyperv-daemons libvarlink-util

# SCP the downloaded rpms to VM
${SCP} -r $1/packages core@api.${CRC_VM_NAME}.${BASE_DOMAIN}:/home/core/

# Install the hyperV and libvarlink-util rpms to VM
${SSH} core@api.${CRC_VM_NAME}.${BASE_DOMAIN} -- 'sudo rpm-ostree install /home/core/packages/*.rpm'

# Remove the packages from VM
${SSH} core@api.${CRC_VM_NAME}.${BASE_DOMAIN} -- rm -fr /home/core/packages

https://github.com/code-ready/snc/blob/67734fb953666881ff45f89de6e6c3fb711e1b30/createdisk.sh#L347-L359

Installing does not automagically activate this, IIRC:

# Adding Hyper-V vsock support
${SSH} core@api.${CRC_VM_NAME}.${BASE_DOMAIN} 'sudo bash -x -s' <<EOF
    echo hv_sock > /etc/modules-load.d/vsock.conf
EOF

so modifcations are needed annyway

[cgruver]

This does sound concerning to me; as this means the snc scripts might have been used but modified and refactored to a point where the hyper-v modifications disappeared? I hope @cgruver can address this and move to a way that the snc scripts get configured to perform an OKD-based install. Ref

The SNC scripts are the same for both OCP and OKD. I'm investigating the apparent failure of the hyperV driver installation or activation during the bundle build.

[cgruver]

I am testing a hypothesis.

The current way that the snc scripts handle the hyperV driver install is by downloading the driver packages to the host system. However, those packages are specific to the host OS kernel and architecture, and may or may not be compatible with the version of CoreOS that they are ultimately installed into.

I suspect that replacing ${SSH} core@api.${CRC_VM_NAME}.${BASE_DOMAIN} -- 'sudo rpm-ostree install /home/core/packages/*.rpm' with ${SSH} core@api.${CRC_VM_NAME}.${BASE_DOMAIN} -- 'sudo rpm-ostree install hyperv-daemons libvarlink-util' may resolve the issue and prevent future issues with CRC for OCP has RHCOS changes to follow FCOS...

It's a theory... testing it this morning.

[cgruver]

I think I found it. FCOS already includes libvarlink-util so the rpm-ostree install command needs the --allow-inactive option. I'm preparing a PR to fix it.

[cgruver]

@daFritz84 I have pushed an updated crc executable.

Would you mind giving it a try? It also does not need a pull secret.

https://dl.fedoraproject.org/pub/alt/okd-crc/windows-amd64/

[daFritz84]

@cgruver works like a charm.
No more manual install of hyperv-daemons 😃

[cgruver]

@vrutkovs This issue is resolved, and can be closed.

[daFritz84]

Thanks again for the fast fix