Feature: CDI Support for riscv64

[ffgan]

Hi there.

I’m ffgan, and I’m glad to share the progress and discussion regarding CDI support for riscv64(rv64) in this issue.

1. Background Discussion

My advisor, nijincheng, previously proposed adding rv64 support for kubevirt in kubevirt#14818. A more detailed discussion later took place on the mailing list: https://groups.google.com/g/kubevirt-dev/c/dObRKg8Stwo/m/y-1Fmcb3AwAJ

In short, we aim to contribute rv64 support to kubevirt. Based on the principle of community-first, we will provide as much assistance as possible to ensure kubevirt runs smoothly on rv64 and continue contributing to its long-term maintenance.

2. Principles of This Issue

As the first step in the above plan, this issue is opened here.

Before starting, we’ll follow two principles to ensure smooth progress:

1. Community first: fully respect community opinions.

2. Thorough discussion: ensure sufficient communication before decisions.

3. Current Status of kubevirt

After continuous effort, we’ve managed to get kubevirt running on rv64. We’re now actively testing kubevirt’s functest. Once that completes, we plan to open related PR to the main kubevirt repo.

The full functest relies on two repositories:

1. https://github.com/kubevirt/containerized-data-importer (CDI)

2. https://github.com/kubevirt/kubevirtci

Therefore, enabling rv64 support for these two repositories is necessary. This issue focuses on adding rv64 support to CDI.

4. Current Status of CDI (Detailed)

Adding rv64 support for CDI is straightforward for Go itself; the real challenges are bazel and k8s. Below I describe each part in detail.

1. Bazel for rv64

Bazel doesn’t officially support rv64 yet, meaning there’s no prebuilt version available.

We need to build bazel from source, for example:

git clone https://gitee.com/kincheng-ni/bazel-v5.4.1.git 
cd bazel-v5.4.1 
# Ensure that OpenJDK 11 is installed 
sudo dnf install java-11-openjdk-devel -y 

./build.sh 

# bazel will be in ./bazel-5.4.1-riscv64/bin/

This repository includes some patches that enable building bazel 5.4.1 on rv64. If needed, I can help mirror this repo into the kubevirt organization.

Regarding Bazel, the following points require special clarification.

Kubernetes has already removed bazel support kubernetes#88553, and kubevirt is discussing the same kubevirt#14038.

According to bazel’s release page:

• Bazel 5.x reached EOL in Jan 2025 (last: 5.4.1)

• Bazel 6.x will reach EOL in Dec 2025

• Bazel 7.x will reach EOL in Dec 2026

Community may need to consider whether to migrate to 7.x or remove bazel entirely.

There are two possible directions: upgrading and migrating to the 7.x version, or removing Bazel entirely. From a long-term perspective, removing Bazel is worth considering. However, the immediate challenge is that removing Bazel requires a massive amount of work — not only deleting all Bazel-related code, but also ensuring correctness and maintaining consistency between the pre- and post-removal states.

If Bazel is not removed, then compatibility issues arising from upgrading to a major version must be carefully considered. Another possible approach is to maintain the current state and wait for a more suitable time to engage in further discussions.

We fully respect the community’s decisions. If the community decides to remove Bazel, we will follow its direction closely and update all rv64-related KubeVirt support accordingly. We will not impose any additional burden on the existing community efforts and will actively assist in completing the related work.

2. Building the builder

When using bazel, we first build the builder image:

git clone https://github.com/ffgan/containerized-data-importer.git
cd containerized-data-importer
git switch rv64

cp ../bazel-v5.4.1/bazel-5.4.1-riscv64/bin/bazel-real hack/build/docker/riscv64/

./build-rv64.sh

In my fork, I’ve modified the build to use fedorariscv/base:41 as the base image.

Then start a local registry:

$ docker run -d -p 5000:5000 --restart always --name registry registry:3

And then we can push the builder image:

$ docker images
REPOSITORY                                                                 TAG                             IMAGE ID       CREATED         SIZE
127.0.0.1:5000/kubevirt/kubevirt-cdi-bazel-builder                         riscv64Test01                   d2fbfa2ea026   4 minutes ago   1.97GB


$ docker push 127.0.0.1:5000/kubevirt/kubevirt-cdi-bazel-builder:riscv64Test01

3. bazel-build

BUILD_ARCH=riscv64 DOCKER_PREFIX="127.0.0.1:5000/kubevirt" QUAY_REPOSITORY=kubevirt-cdi-bazel-builder BUILDER_TAG=riscv64Test01 BUILDER_IMAGE=${DOCKER_PREFIX}/${QUAY_REPOSITORY}:${BUILDER_TAG} make bazel-build

Running bazel-build on rv64 requires multiple fixes.

1. bazeldnf

The first modification needed is to update the RPM package dependencies by adding packages for rv64. This requires using bazeldnf. Currently, bazeldnf does not directly support rv64, so I used a modified version from this repository.

However, bazeldnf has a bug on rv64 that prevents it from being used to update KubeVirt dependencies directly. Details can be found in this issue. This problem may be related to the package repository being used and not necessarily to rv64 itself.

To enable bazeldnf support for rv64, I submitted a pull request. If the PR is successfully merged, I will attempt again to use bazeldnf on rv64 to update KubeVirt dependencies and submit a new PR to resolve this issue.

In the meantime, to update CDI’s RPM dependencies for rv64, I used the script from this repository with minor modifications. I placed the modified script in my own repository at https://github.com/ffgan/rpm-deps, used it to generate RPM dependencies suitable for rv64, and then manually pasted the results back into CDI.

To summarize:

We needed bazeldnf to work during Bazel’s analyze phase on rv64, so we used a custom bazeldnf repository. However, due to a bug, we couldn’t use make rpm-deps directly. Instead, I used a handwritten Python script to generate the required dependencies and then manually copied them back into CDI.

2. rules_go

Since rules_go does not directly support rv64, I submitted a simple PR to make rules_go work better under rv64. By upgrading to version 0.59.0, it can function properly on rv64. However, rules_go 0.59.0 requires Bazel 6.5.0 or higher, while our current Bazel version is 5.4.1.

Considering the earlier discussion about Bazel version compatibility, I believe we need to decide whether to upgrade to Bazel 7.x. If we don’t plan to upgrade, we can instead use a forked repository: https://github.com/Boring545/rules_go/releases/download/v0.46.0. With this version of rules_go, we won’t need to upgrade Bazel. If using a third-party repository raises security or maintenance concerns, I can help mirror this repository into the kubevirt organization to ensure availability and maintainability.

To minimize the amount of change introduced, I am currently using the latter approach.

With that in place, we can successfully run bazel-build.

4. build-functest

BUILD_ARCH=riscv64 DOCKER_PREFIX="127.0.0.1:5000/kubevirt" QUAY_REPOSITORY=kubevirt-cdi-bazel-builder BUILDER_TAG=riscv64Test01 BUILDER_IMAGE=${DOCKER_PREFIX}/${QUAY_REPOSITORY}:${BUILDER_TAG} make build-functest

The results show that everything went smoothly, with nothing significant to note.

5. test-unit

BUILD_ARCH=riscv64 DOCKER_PREFIX="127.0.0.1:5000/kubevirt" QUAY_REPOSITORY=kubevirt-cdi-bazel-builder BUILDER_TAG=riscv64Test01 BUILDER_IMAGE=${DOCKER_PREFIX}/${QUAY_REPOSITORY}:${BUILDER_TAG} make test-unit

When running test-unit, since there is no available quay.io/prometheus/prometheus container for rv64, we need to manually build it. This process is rather involved, but in short, we need to build the Prometheus's rv64 image and tag it as quay.io/prometheus/prometheus:v2.44.0.

Due to several limitations, we can only build the rv64 Prometheus image through cross-compilation on x86:

make promu
promu crossbuild -p linux/riscv64
make npm_licenses
make common-docker-riscv64

After building, we also need to manually tag it as quay.io/prometheus/prometheus:v2.44.0.

I’ve already submitted a PR to Prometheus regarding this process — see prometheus/prometheus#17508.

Once the above steps are complete, we can proceed to run test-unit.

Here’s one of the execution results:

test-unit.log

Overall, it runs smoothly; you can refer to the log for details. There are indeed some errors, but now is not the time to address them. For the moment, we can consider the test as having passed successfully.

6. format

BUILD_ARCH=riscv64 DOCKER_PREFIX="127.0.0.1:5000/kubevirt" QUAY_REPOSITORY=kubevirt-cdi-bazel-builder BUILDER_TAG=riscv64Test01 BUILDER_IMAGE=${DOCKER_PREFIX}/${QUAY_REPOSITORY}:${BUILDER_TAG} make format

The results show that everything went smoothly, with nothing significant to note.

7. vet

BUILD_ARCH=riscv64 DOCKER_PREFIX="127.0.0.1:5000/kubevirt" QUAY_REPOSITORY=kubevirt-cdi-bazel-builder BUILDER_TAG=riscv64Test01 BUILDER_IMAGE=${DOCKER_PREFIX}/${QUAY_REPOSITORY}:${BUILDER_TAG} make vet

The output of the last part is as follows. It’s likely due to an existing bug, not caused by rv64. Let’s consider it as a pass for now.

# kubevirt.io/containerized-data-importer/pkg/importer
# [kubevirt.io/containerized-data-importer/pkg/importer]
./gcs-datasource.go:61:7: the cancel function returned by context.WithTimeout should be called, not discarded, to avoid a context leak
+ finish
+ docker stop --time 1 cf9b7df1c052941349d79d50cc2c9497bac92f41c9591631d1bfb1c11deae0f0
+ docker rm -f cf9b7df1c052941349d79d50cc2c9497bac92f41c9591631d1bfb1c11deae0f0
make: *** [Makefile:218: vet] Error 1

8. bazel-build-images

BUILD_ARCH=riscv64 DOCKER_PREFIX="127.0.0.1:5000/kubevirt" QUAY_REPOSITORY=kubevirt-cdi-bazel-builder BUILDER_TAG=riscv64Test01 BUILDER_IMAGE=${DOCKER_PREFIX}/${QUAY_REPOSITORY}:${BUILDER_TAG} make bazel-build-images

Since this part involves building containers, the rules_docker used here also doesn’t support rv64. Therefore, we use a modified version of rules_docker, as shown below:

http_archive(
    name = "io_bazel_rules_docker",
    sha256 = "f5d26fcba1a99597a275e9a18971a4dcf44aecb109ccf8f080d080f1e6d9a10b",
    strip_prefix = "rules_docker-0.16.0",
    urls = [
        "https://github.com/Boring545/rules_docker/releases/download/v0.16.0/rules_docker-v0.16.0.zip",
    ],
)

If we want rules_docker to officially support rv64, the situation becomes a bit more complicated. rules_docker has already been deprecated, and the maintainer suggested switching to rules_oci instead. See this PR for details. However, rules_oci doesn’t handle RPMs very well, which makes things a bit troublesome.

If necessary, I might consider submitting a PR to add rv64 support to rules_oci in the future, but for now, it will be put on hold.

9. bazel-push-images

BUILD_ARCH=riscv64 DOCKER_PREFIX="127.0.0.1:5000/kubevirt" QUAY_REPOSITORY=kubevirt-cdi-bazel-builder BUILDER_TAG=riscv64Test01 BUILDER_IMAGE=${DOCKER_PREFIX}/${QUAY_REPOSITORY}:${BUILDER_TAG} make bazel-push-images

It can also be executed smoothly, with no additional notes required.

10. test-lint

BUILD_ARCH=riscv64 DOCKER_PREFIX="127.0.0.1:5000/kubevirt" QUAY_REPOSITORY=kubevirt-cdi-bazel-builder BUILDER_TAG=riscv64Test01 BUILDER_IMAGE=${DOCKER_PREFIX}/${QUAY_REPOSITORY}:${BUILDER_TAG} make test-lint

Lack of a quay.io/kubevirt/prom-metrics-linter container for rv64.

This container comes from kubevirt/monitoring and depends on distroless/base. There is currently a related issue: GoogleContainerTools/distroless#1269.

It has been modified to use an Alpine image, see ffgan/monitoring prom-metrics-linter container.

It can now run successfully.

11. Other build targets

For other targets, such as cluster-*, since Kubernetes does not yet officially support rv64, the relevant issue can be found here: kubernetes/kubernetes#116686. It is foreseeable that official rv64 support in Kubernetes will not be available in the short term.

However, this is not a problem—I have already tried deploying rv64's k3s, and it works properly. If we want cluster-* to be supported as well, I estimate that it would be a much larger topic, and it would be more appropriate to open a separate issue to address it. If consensus can be reached on the current issue, I believe I can soon open a new issue to elaborate on this and further promote the related progress.

12. Target's State

target name	status
bazel-build	Y
build-functest	Y
test-unit	Y
format	Y
vet	Y
bazel-build-images	Y
bazel-push-images	Y
test-lint	Y
cluster-*	N

13. Forked repositories used

Name	URL	Description
bazel	https://gitee.com/kincheng-ni/bazel-v5.4.1.git	Build Bazel for rv64
rules_go	https://github.com/Boring545/rules_go/releases/download/v0.46.0/rules_go-v0.46.0.zip	Enables Bazel’s Go toolchain to work on rv64
rules_docker	https://github.com/Boring545/rules_docker/releases/download/v0.16.0/rules_docker-v0.16.0.zip	Enables Bazel’s Docker toolchain to work on rv64
bazeldnf	https://gitee.com/huang_a/bazeldnf/releases/download/v0.5.9/bazeldnf-v0.5.9.tar.gz	Allows Bazeldnf to run on rv64, but rpm-deps cannot be executed
bazeldnf-script	https://github.com/ffgan/rpm-deps.git	Used to generate RPM package dependencies on rv64

5. Current Status of CDI (Summary)

In summary, the current state of rv64 support in CDI is as follows:

CDI can basically be built and tested on rv64, and is overall usable on rv64. However, due to the lack of rv64 support in k8s, it is currently not possible to build all targets.

6. Discussion Regarding PRs

The above summarizes my recent attempts and results regarding CDI support for rv64. If there is anything incorrect, please feel free to point it out directly.

Regarding this issue, I hope we can discuss plans and approaches for CDI’s rv64 support, mainly focusing on the following points:

1. How to handle upstream repositories that do not support rv64

The obvious approach is to submit a PR to the upstream repository and wait for the upstream release to gain the required support. In fact, I have submitted a PR to rules_go upstream and am waiting for the release. However, the latest upstream versions often have minimum requirements—for example, rules_go 0.59.0 works on rv64 but requires Bazel 6.5.0, which conflicts with CDI.

A more reasonable approach is to follow upstream as closely as possible and upgrade our Bazel version. However, we understand that upgrading versions is not always easy, so we could also consider using our own fork to achieve rv64 support on lower versions. If we go with our own fork, I can assist the KubeVirt community in maintaining it: cloning all relevant forks and managing them under the KubeVirt GitHub organization to ensure usability. Other better approaches are also welcome.

Regarding this matter, I adhere to the principle of respecting the community’s opinion. Once a consensus is reached, I will promptly update the information regarding CDI’s rv64 support to ensure that CDI achieves robust rv64 compatibility.

2. Plan for CDI rv64 Support

My preliminary plan is to first have the community discuss the issues mentioned above, and then I will gradually submit the smallest possible PRs—following the principle of minimizing the PR review burden—to progressively enable CDI support for rv64.

1. Resolve certain upstream dependency issues.
2. Provide initial support for building CDI on rv64.
3. Address issues related to starting clusters on rv64.
4. Add CI coverage for rv64.
5. Improve testing on rv64.
6. Achieve full support for rv64.

Before completing the previous step, the next step should be avoided as much as possible to prevent excessive maintenance burden.

3. Regarding Cluster Startup Issues

Starting a cluster depends on k8s support for rv64. I do not intend to address this issue within this issue because it is too large in scope; I will open a separate issue to handle it. This cluster-related problem is not only present in CDI but also exists in KubeVirt, and it is also related to kubevirtci.

7. Additional Information

If you have any questions or concerns about the above, please feel free to ask — I’m happy to provide further details.

I hope this contribution can help kubevirt progress further toward rv64 support.

---

Co-authored by: nijincheng@iscas.ac.cn
Co-authored by: 1768549509@qq.com
Co-authored by: 545247976@qq.com

[awels]

Hello @ffgan

Thank you for this comprehensive proposal. There is a lot to go over so give me a bit to read it in more detail. I think it would be good to discuss this is in more detail at the sig-storage meeting. You can find the details on when the next meeting is in the kubevirt calendar.

Alexander

[ffgan]

Hello @ffgan

Thank you for this comprehensive proposal. There is a lot to go over so give me a bit to read it in more detail. I think it would be good to discuss this is in more detail at the sig-storage meeting. You can find the details on when the next meeting is in the kubevirt calendar.

Alexander

Thanks for your reply. However, I may not be able to attend the related meeting. If there is any additional information, I will update it in this issue. If you have any questions, feel free to @ me directly — I’m more than happy to answer anything related.

[awels]

Okay, this meeting is biweekly so if other times work for you feel free to join. I will mention this proposal during the next meeting to see what others think and get some more eyes on it. We already have support for arm and s390x so adding another aarch should not be super hard.

[awels]

While going over the proposal I would like to note that running the functional tests in either KubeVirt or CDI does NOT require kubevirtci. kubevirtci is a simple and easy way for people to spin up an ephemeral kubernetes cluster, with a variety of properties that we would want to test. It is entirely possible to run the functional tests against an existing cluster where you have deployed kubevirt and/or cdi. To run against an external cluster you have to set a few environment variables:

• DOCKER_REPO this is the name of the registry you want to write the containers to. If you don't set this, it will default to the registry exposed by kubevirtci. But if you a personal quay repo (like I do) you can do something like this export DOCKER_REPO=quay.io/awels and when you do a make docker-push (which is called as part of make cluster-sync) it will push the container into the repo you have specified. You also have to be logged into the repo for this to work. Secondly make manifests will use this to build the deployment manifests pointing to your repository.
• KUBEVIRT_PROVIDER this is normally used to determine which version kubernetes to use for kubevirtci. However if you specify external it will use kubectl to deploy to whatever cluster your KUBECONFIG points to.
• KUBECONFIG normally this points to the kubeconfig for kubevirtci if you are using it, but you can point it to a kubeconfig file that gives you access to an external cluster.

Setting up those env variables will allow you to deploy to an existing external cluster. In order to run the functional tests for CDI against the cluster, take a look at hack/build/run-functional-tests.sh for any other env variables to set before running the tests. You can do this against an external cluster as well. This is a standard ginkgo test, so you use any ginkgo flags to skip tests if they make no sense for your cluster.

Will going through the rest of the proposal, but I don't think you should spend time trying to make kubevirtci work on risc since you don't need it.

[awels]

One more note, we are working on updating bazel to use rules_oci, see this PR

[ffgan]

Will going through the rest of the proposal, but I don't think you should spend time trying to make kubevirtci work on risc since you don't need it.

Thank you for your reply.

As you mentioned, running kubevirt and CDI does not require kubevirtci. We previously tested KubeVirt on rv64, and its overall status is mostly the same as CDI’s current state — the regular unit tests all passed. However, the functional tests have not fully passed yet. The reason, as I observed, is that using the cluster* scripts involves a series of complex startup procedures, such as configuring clusters, launching various containers, and so on. This makes it difficult for the functional tests to complete successfully.

Because of this, I was wondering whether we should first add rv64 support to kubevirtci so that these scripts can be used directly, rather than trying to infer which component needs adjustment based on failing test cases, where the corresponding startup scripts are located, and which ones behave differently when using an external cluster. Of course, this might also be because I haven’t thoroughly read the documentation.

But since kubevirtci is not required, I will temporarily set aside rv64 support for the cluster* scripts and instead try testing CDI on rv64 using an external cluster. I will provide updates here as soon as I have more results.

[ffgan]

One more note, we are working on updating bazel to use rules_oci, see this PR

I’m very glad to see that CDI is trying to switch to rules_oci. I will actively work on adding rv64 support for rules_oci. By the way, I recently added rv64 support to regclient, one of the upstream dependencies of rules_oci — see regclient/regclient#1011
.

We will continue contributing directly upstream so that we can eventually obtain artifacts that work on rv64 out of the box.

[ffgan]

I will mention this proposal during the next meeting to see what others think and get some more eyes on it.

Thank you for your attention to this proposal. I’m very much looking forward to the outcome of the meeting, and I hope we can contribute more to KubeVirt together.

We already have support for arm and s390x so adding another aarch should not be super hard.

Yes. Go has good support for different architectures, so adding support for a new architecture is not a difficult task.

[ffgan]

One more note, we are working on updating bazel to use rules_oci, see this PR

Since kubevirt is using Bazel 6.5.0, may I ask whether CDI can also use 6.5.0? If so, I’ll go ahead and try whether the rv64 version of Bazel can successfully build and start CDI.

[awels]

Because of this, I was wondering whether we should first add rv64 support to kubevirtci so that these scripts can be used directly, rather than trying to infer which component needs adjustment based on failing test cases, where the corresponding startup scripts are located, and which ones behave differently when using an external cluster. Of course, this might also be because I haven’t thoroughly read the documentation.

The functional tests should be completely independent of the cluster we run against. We realize not all clusters will provide all the functionality needed to execute all tests. This is why we provide the e2e test binary as a separate artifact (amd64 only) so people can run the functional test against whatever cluster they want. If you can build the e2e test binary on risc you should be able to run it against whatever cluster you want assuming you provide it the correct arguments. Since CDI is mainly concerned with getting disk images into your cluster, you can actually run CDI on a cluster without KubeVirt installed, they are completely independent from each other in the regard (KubeVirt requires CDI from some specific functionality, but that is basically the only real dependency).

I don't know exactly what type of storage you have available for your cluster. This question is important because depending on your answer some tests can be skipped because they are not relevant.

[awels]

One more note, we are working on updating bazel to use rules_oci, see this PR

Since kubevirt is using Bazel 6.5.0, may I ask whether CDI can also use 6.5.0? If so, I’ll go ahead and try whether the rv64 version of Bazel can successfully build and start CDI.

I believe the goal of the PR I mentioned is to get bazel up to the same version as KubeVirt.

[ffgan]

In fact, since k8s does not yet support rv64, the cluster we use for testing is deployed with k3s on rv64. We are able to run kubevirt without issues and successfully launch virtual machines such as Alpine, Fedora, and Buildroot.

For the functest, I did not run the entire suite; I only ran some of the tests. I noticed a few failures indicating that a CDI-enabled cluster was required, which made me start considering whether CDI should also add rv64 support.

Of course, we would like to have all tests passing. However, if some tests fail simply because the cluster does not provide the required functionality, then we can skip those tests.

[ffgan]

Status Update

0. Summary

Currently in the phase of waiting for upstream community releases or preparing to submit PRs.

1. bazeldnf

Regarding bazeldnf, the upstream has accepted the PR. Now we need to wait for bazeldnf to release a new version to obtain rv64 support. However, one thing to note is that since rules_go v0.59.0 was used to obtain rv64 support, we need to upgrade the bazel version to 6.5.0 or above to properly use the rv64 version of bazeldnf. This means we need to wait until CDI can use bazel 6.5.0 before we can use the rv64 version of bazeldnf.

Testing has confirmed that the rv64 version of bazeldnf works normally. It is expected that there will be no blocking issues here.

2. rules_oci

Regarding rules_oci, I am currently actively working on adding rv64 support for it. The previously mentioned regclient has been merged. Another upstream dependency, go-containerregistry, has also been merged. Both are waiting for releases to obtain usable rv64 versions. Since they were just merged recently, we need to be patient and wait for the maintainers to release new versions. After both are released, I will promptly submit a PR for rules_oci to support rv64.

Similarly, it is expected that there will be no blocking issues here, it's just a matter of time.

3. functest

Regarding functest, this requires a special section to describe this content, but I will try to organize the relevant information and explain everything clearly.

3.1. Overall Situation

Here are the results from my most recent test run:

Ran 435 of 654 Specs in 15990.407 seconds
FAIL! -- 375 Passed | 60 Failed | 3 Pending | 216 Skipped
--- FAIL: TestTests (15990.47s)
FAIL

Ginkgo ran 1 suite in 4h26m30.62295183s

Test Suite Failed

For details, please see full-test.log

I believe these test results are still within expectations. I don't want to make too much analysis before completing all tests, as that would be biased. In short, I will prioritize testing those 60 failed cases, then consider the skipped tests. After completing these two, I'll consider running a complete test again.

Below I will introduce the detailed content about the testing.

3.2. Test Environment

I set up k3s + rv64 on my server without configuring NFS, cephFS, or any other storage. I simply brought up the cluster and deployed CDI. As a result, many tests were skipped. Subsequently, I will gradually add relevant storage and conduct related tests.

3.3. Test Commands

export KUBEVIRT_PROVIDER=external
export DOCKER_PREFIX=127.0.0.1:5000/kubevirt
export KUBECONFIG=~/.kube/config
export IMAGE_PULL_POLICY=Always
export DOCKER_TAG=riscv64Test01

# output
# make cluster-up
# ./cluster-up/up.sh
# /usr/local/bin/kubectl
# which: no oc in (/root/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/home/xiaofei/spdk/build/bin)
# Cluster is up


BUILD_ARCH=riscv64 DOCKER_PREFIX="127.0.0.1:5000/kubevirt" QUAY_REPOSITORY=kubevirt-cdi-bazel-builder BUILDER_TAG=riscv64Test01 BUILDER_IMAGE=${DOCKER_PREFIX}/${QUAY_REPOSITORY}:${BUILDER_TAG} make test-functional

3.4. Custom Images

A custom image used is MinIO. MinIO is special as it doesn't provide rv64 images. (I previously submitted a PR to MinIO for rv64 support, which has been merged, meaning it has been tested to run smoothly and pass all tests on rv64). Since CDI needs to use MinIO during testing, I needed to manually build a MinIO image. The specific repository can be found here: https://github.com/ffgan/minio/tree/rv64.

I manually modified the default Dockerfile to make it work on rv64. Testing shows it works normally.

3.5. Content Not Yet Supported

One thing not yet supported is imageIO, because ovirt-imageio-client requires manually building rv64 RPM packages. I noticed there is a copr configuration in https://github.com/oVirt/ovirt-imageio, but I'm not very familiar with using copr yet. Once I figure it out, I will complete the packaging in a new github repo and release an rv64 RPM package for direct download.

Because imageIO is not yet supported, some tests will fail here, which is expected.

Similarly, since I'm not very familiar with CDI content at the moment, I may have errors, omissions, or unclear descriptions regarding some configurations and k8s-related content. If so, please don't hesitate to point them out directly at any time, and I will immediately correct them. Because of this, some tests may fail or be skipped, perhaps because I haven't fully understood the relevant content. If there are any suggestions or corrections regarding this, please feel free to @ me directly.

3.6. Test Conclusions

I preliminarily believe that the test results show CDI can run well on rv64, mainly due to Go's excellent support for different architectures. This means we don't need to make too many modifications to CDI to achieve rv64 support. The modifications are concentrated on its upstream dependencies or issues related to the testing environment, which is also my current main focus.

4. What We Can Do Now to Accelerate CDI's rv64 Support

I believe the main points are:

1. Assist CDI in switching to rules_oci
2. Assist CDI in upgrading the bazel version to 6.5.0
3. More discussion about upstream dependencies that don't yet support rv64 (I will explicitly point out all these dependencies)
4. Review my complete functest logs, and if there are any suggestions, please point them out directly

5. Finally

If you have any questions about the above content, please @ me directly. I'm happy to answer all questions.

[akalenyu]

/cc