Allow VM machine type to be set dynamically

[carterpewpew]

What this PR does / why we need it:

Adds multi-architecture support for VM machine type in the test framework. Previously, the machine type was hardcoded to q35, which is x86_64-specific. This caused all VM and VMI creation to be rejected by the KubeVirt admission webhook on s390x with:

spec.template.spec.domain.machine.type is not supported: q35 (allowed values: [s390-ccw-virtio*])

This PR:

• Introduces InitDefaultMachineType() which auto-detects the cluster architecture from node info and sets the appropriate machine type (s390-ccw-virtio for s390x, virt for arm64, q35 for amd64)
• Supports an env var override (KVP_DEFAULT_MACHINE_TYPE) for manual control
• Replaces all hardcoded q35 references in Go test specs with the detected default
• Updates RunKubectlCreateYamlCommand to substitute type: q35 in YAML manifests at apply time
• Routes CreateVMWithPVC and CreateVMIWithDataVolume through the YAML substitution pipeline (they previously bypassed it via raw RunKubectlCommand)

Validated on an s390x OpenShift cluster: machine type correctly detected as s390-ccw-virtio, VMs created and reached Running state without admission webhook rejections.

Which issue(s) this PR fixes:
Fixes test failures on s390x clusters where all VM-based tests fail due to hardcoded q35 machine type.

Special notes for your reviewer:

• The 8 YAML manifests under tests/manifests/ still contain type: q35 as a placeholder. This is intentional -- RunKubectlCreateYamlCommand rewrites it at apply time via sed. Changing the YAML files themselves was avoided to keep the diff minimal and because the sed-based substitution was already the established pattern for {{KVP_STORAGE_CLASS}}.
• The manifests_utils.go changes for CreateVMWithPVC and CreateVMIWithDataVolume are necessary because they were the only two VM/VMI-creating functions using raw RunKubectlCommand instead of RunKubectlCreateYamlCommand, meaning neither storage class nor machine type substitution was happening for them.

Release note:

NONE

[kubevirt-bot]

Hi @carterpewpew. Thanks for your PR.

PRs from untrusted users cannot be marked as trusted with /ok-to-test in this repo meaning untrusted PR authors can never trigger tests themselves. Collaborators can still trigger tests on the PR using /test all.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[alromeros]

/ok-to-test

[alromeros]

@carterpewpew PR looks great, thanks! Just one nit about the commits. We generally prefer to avoid merge commits in the history. It’s better to just rebase and address the changes there.
/test all
/approve

[kubevirt-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alromeros

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [alromeros]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[carterpewpew]

@carterpewpew PR looks great, thanks! Just one nit about the commits. We generally prefer to avoid merge commits in the history. It’s better to just rebase and address the changes there. /test all /approve

Thanks for the review and the feedback! I've rebased the branch to remove the merge commit.

[alromeros]

/test all