kubevirt / common-instancetypes Goto Github PK

/kind enhancement

The current structure is pretty nested and could be simplified, for example:

$ tree common-instancetypes/instancetypes/hyperscale/n/
common-instancetypes/instancetypes/hyperscale/n/
├── 1
│   ├── 2xlarge
│   │   └── kustomization.yaml
│   ├── 4xlarge
│   │   └── kustomization.yaml
│   ├── 8xlarge
│   │   └── kustomization.yaml
│   ├── base
│   │   ├── kustomization.yaml
│   │   └── n1.yaml
│   ├── kustomization.yaml
│   ├── large
│   │   └── kustomization.yaml
│   ├── medium
│   │   └── kustomization.yaml
│   └── xlarge
│       └── kustomization.yaml
├── base
│   ├── kustomization.yaml
│   └── n.yaml
├── kustomization.yaml
└── sizes
    ├── 2xlarge
    │   ├── 2xlarge.yaml
    │   └── kustomization.yaml
    ├── 4xlarge
    │   ├── 4xlarge.yaml
    │   └── kustomization.yaml
    ├── 8xlarge
    │   ├── 8xlarge.yaml
    │   └── kustomization.yaml
    ├── large
    │   ├── kustomization.yaml
    │   └── large.yaml
    ├── medium
    │   ├── kustomization.yaml
    │   └── medium.yaml
    └── xlarge
        ├── kustomization.yaml
        └── xlarge.yaml

17 directories, 24 files

As compared to https://github.com/fabiand/instanceTypes/tree/main/series/n1

/kind enhancement

For example:

https://github.com/fabiand/instanceTypes/blob/main/series/n1/n1.yaml#L16

    series.icon.pf: pf-icon-network

What happened:

$subject

What you expected to happen:

This behaviour to be automated.

How to reproduce it (as minimally and precisely as possible):

Release a non-latest version of common-instancetypes.

Additional context:
Add any other context about the problem here.

Environment:

• KubeVirt version (use virtctl version): N/A
• Kubernetes version (use kubectl version): N/A
• VM or VMI specifications: N/A
• Cloud provider or hardware configuration: N/A
• OS (e.g. from /etc/os-release): N/A
• Kernel (e.g. uname -a): N/A
• Install tools: N/A
• Others: N/A

/kind enhancement

kubevirt/project-infra#2582

/kind bug

What happened:

$subject

/kind bug
/cc @RoniKishner

What happened:

The o1 series (overcommit) VirtualMachineClusterInstancetype we deploy are missing cpy/memory labels:

• instancetype.kubevirt.io/cpu
• instancetype.kubevirt.io/memory

Those labels help in getting a list of optional resources which we can chose from.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

https://bugzilla.redhat.com/show_bug.cgi?id=2223539

Environment:

• KubeVirt version (use virtctl version):
• Kubernetes version (use kubectl version):
• common-templates version:
• VM or VMI specifications:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

/kind enhancement

See the following for an example:

https://github.com/fabiand/myInstanceTypes

/kind enhancement

What happened:

kubevirt/kubevirt#8780

As supported in v1beta1 add these to the resources generated by the project.

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug
/kind enhancement

What happened:

Using a compute or memory instance type requires a node with huge pages support, which is not a default setting, so out of the box, compute and memory instance types are unusable.

When trying to create a VM in one of these instance types, it fails with an unhelpful error that points to scheduling, but does not mention huge pages as the reason.

What you expected to happen:

Either better messaging to bring to light the lack of huge pages or another way to introduce to admins the ability to require huge pages in an instance type.

How to reproduce it (as minimally and precisely as possible):

Create a vm with compute or memory instance type on a cluster where nodes do not have huge page support.

Anything else we need to know?:

Huge pages make sense across the board for VM handling nodes, but fine tuning the number of huge pages per compute node is a per-cluster exercise, and fits better in a performance and tuning guide than a default.

/kind enhancement

What happened:

$subject, once kubevirt/kubevirt#9744 lands in KubeVirt.

Is this a BUG REPORT or FEATURE REQUEST?:

Uncomment only one, leave it on its own line:

/kind bug

/kind enhancement

What happened:

Windows 11 requires at least two cores (see here) but the preferences in common-instancetypes require only one CPU.

What you expected to happen:

Preferences should require at least two CPUs.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• KubeVirt version (use virtctl version):
• Kubernetes version (use kubectl version):
• common-templates version:
• VM or VMI specifications:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

Is your feature request related to a problem? Please describe:

The repository is making extensive use of kustomize, which at some places makes it harder than necessary to understand how everything comes together.

Describe the solution you'd like:

We should try to flatten the repo structure and avoid unnecessary deeply nested directory structures and workarounds to Kustomize's behavior where possible.

E.g. it would be nice to flatten instancetypes from this

instancetypes/cx:
1 VirtualMachineClusterInstancetype VirtualMachineInstancetype kustomization.yaml

to this:

instancetypes/cx1:
cx1.yaml sizes.yaml kustomization.yaml

Describe alternatives you've considered:
A clear and concise description of any alternative solutions or features you've considered.

Additional context:
Add any other context or screenshots about the feature request here.

/kind enhancement

What happened:

Useful for understanding where the resource came from, will need to be updated when cutting a release.

/kind bug

What happened:

#49

There's no coverage ensuring that the resource labels are correct at present. This could easily be added to the functest job or as a standalone static check after generation.

What happened:

$subject, this can result in unbootable guests when using BitLocker encryption.

What you expected to happen:

Persistent TPM storage to be provided by the Windows 11 and 2k22 preferences to avoid guests using BitLocker encryption becoming unbootable.

How to reproduce it (as minimally and precisely as possible):

• Boot a Windows 11/2k22 VM using the associated preferences
• Use BitLocker encryption within the guest
• Reboot

Additional context:

Reported downstream against CNV v4.16.0 https://issues.redhat.com/browse/CNV-39710

Environment:

• KubeVirt version (use virtctl version): N/A
• Kubernetes version (use kubectl version): N/A
• VM or VMI specifications: N/A
• Cloud provider or hardware configuration: N/A
• OS (e.g. from /etc/os-release): N/A
• Kernel (e.g. uname -a): N/A
• Install tools: N/A
• Others: N/A

/kind enhancement

What happened:

$subject, these would be useful as labels as we could do things like the following:

$ kubectl get virtualmachineclusterinstancetypes \
    -linstancetype.kubevirt.io/class=Overcommitted

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• KubeVirt version (use virtctl version):
• Kubernetes version (use kubectl version):
• common-templates version:
• VM or VMI specifications:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

/kind enhancement

See https://github.com/fabiand/instanceTypes for an example

/kind bug

What happened:

The current CentOS 9 Stream cloud images do not support UEFI boot:

$ virt-filesystems -a CentOS-Stream-GenericCloud-9-latest.x86_64.qcow2 --all --long --uuid -h
Name      Type       VFS Label MBR Size Parent   UUID
/dev/sda1 filesystem xfs -     -   7.8G -        a2e35d7f-1574-4fc3-aebd-5e60991d3841
/dev/sda1 partition  -   -     83  7.8G /dev/sda -
/dev/sda  device     -   -     -   10G  -        -

As such using the current centos.stream9 preference that enables efi and secureboot leads to an unbootable guest:

$ virtctl create vm --instancetype u1.medium   --preference centos.stream9 --volume-containerdisk name:centos,src:quay.io/containerdisks/centos-stream:9   --name centos | kubectl apply -f -
[..]
$ virtctl console centos
[..]
BdsDxe: failed to load Boot0001 "UEFI Misc Device" from PciRoot(0x0)/Pci(0x2,0x6)/Pci(0x0,0x0): Not Found
BdsDxe: No bootable option or device was found.
BdsDxe: Press any key to enter the Boot Manager Menu.

What you expected to happen:

efi and secureboot are not enabled within the centos.stream9 preference until UEFI boot is supported by the cloud images and associated kubevirt/containerdisks.

How to reproduce it (as minimally and precisely as possible):

As above.

Anything else we need to know?:

Found downstream by https://issues.redhat.com/browse/CNV-32936

Environment:

• KubeVirt version (use virtctl version):
• Kubernetes version (use kubectl version):
• common-templates version:
• VM or VMI specifications:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

Is this a BUG REPORT or FEATURE REQUEST?:

/kind bug

What happened:
typo, should be based on U series

https://github.com/kubevirt/common-instancetypes/blob/main/common-instancetypes/instancetypes/hyperscale/o/base/o.yaml#L8

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• KubeVirt version (use virtctl version):
• Kubernetes version (use kubectl version):
• common-templates version:
• VM or VMI specifications:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

Is this a BUG REPORT or FEATURE REQUEST?:
Currently Network (N series) and Compute Exclusive (CX series) differ by only one aspect: vNUMA:

vNUMA - Physical NUMA topology is reflected in the guest in order to optimize guest sided cache utilization.

However the network use case also requires vNUMA for it's proper work. For example, DPDK workloads require the CPUs scheduled for the VM to be of the same NUMA node. This is currently done by using the Node Tuning Operator in order to enforce "single-numa-topology".
Please consider joining these two use cases, as it can reduce your maintenance work in this project.

Uncomment only one, leave it on its own line:

/kind bug
/kind enhancement

What happened:

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• KubeVirt version (use virtctl version):
• Kubernetes version (use kubectl version):
• common-templates version:
• VM or VMI specifications:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

/kind bug

What happened:

Missed by #44

$ git grep -l instancetype.kubevirt.io/v1alpha2
common-instancetypes-all-bundle.yaml
common-instancetypes-bundle.yaml
common-instancetypes/instancetypes/base/VirtualMachineInstancetype.yaml

/kind bug

What happened:

/kind enhancement

What happened:

Super useful for testing in small dev envs when using something like CirrOS or Alpine.

What you expected to happen:

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

Environment:

• KubeVirt version (use virtctl version):
• Kubernetes version (use kubectl version):
• common-templates version:
• VM or VMI specifications:
• Cloud provider or hardware configuration:
• OS (e.g. from /etc/os-release):
• Kernel (e.g. uname -a):
• Install tools:
• Others:

/kind enhancement

What happened:

$subject, for now these values are hard-coded into each preference but eventually this process should be automated as it is in common-templates.

https://github.com/kubevirt/common-templates/blob/master/generate-templates.yaml

/kind bug

What happened:

#46 copies this value from common-templates. This issue is just to track the investigation of why that was required, if it is still required and possible documentation required as a result so this justification isn't lost again in the future.

/kind enhancement

What happened:

$ kubectl get virtualmachineclusterinstancetypes \
    -linstancetype.kubevirt.io/deprecated=true
selecting podman as container runtime
NAME                     AGE
highperformance.large    3h53m
highperformance.medium   3h53m
highperformance.small    3h53m
server.large             3h53m
server.medium            3h53m
server.micro             3h53m
server.small             3h53m
server.tiny              3h53m

/kind enhancement

As set out in the following PR for @fabiand's version of common-instancetypes a network specific workload instance type would be useful:

fabiand/instanceTypes#3

Note this includes renaming the neutral / generic instance types.

/kind enhancement

What happened:

This class duplicates the U class with the addition of memory overcommit however the current implementation in the repo copies the entire kustomization structure. This can and should be simplified to just inherit N into O with the addition of memory covercommit.

/kind bug

Tracking bug for the following KubeVirt bug and PR:

kubevirt/kubevirt#9102

kubevirt/kubevirt#9103

$ make cluster-down && make cluster-up && make cluster-sync && make cluster-functest
[..]
virtualmachine.kubevirt.io "vm-highperformance.small" deleted
selecting docker as container runtime
The request is invalid: spec.template.spec.domain.resources.requests.memory: spec.template.spec.domain.resources.requests.memory '0' must be equal to or larger than page size spec.template.spec.domain.hugepages.size '2Mi'
functest failed on instance type m1.2xlarge
make: *** [Makefile:51: cluster-functest] Error 1

/kind enhancement

Once kubevirt/kubevirt#9575 lands move all resources to v1beta1.