Consider merging CX and N use-cases

[RamLavi]

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:

[kubevirt-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[fabiand]

I'd say that vNUME generally makes sense in CX as well.

But even if the two series become functionally equal, I wonder if we should merge them.

For higher level tooling - such as UI and automatoin - it can be helpful to know the purpose or intention of the workload.

[fabiand]

/remove-lifecycle stale