> On Tue, Feb 22, 2022 at 9:48 AM Simone Tiraboschi <stirabos(a)redhat.com>
> wrote:
>
>
> Just to clarify the state of things a little: It is not only technically
> there. KubeVirt supports pci passthrough, GPU passthrough and
> SRIOV (including live-migration for SRIOV). I can't say if the OpenShift UI
> can compete with oVirt at this stage.
>
>
> Best regards,
> Roman
Well, I guess it's there, mostly because they didn't have to do anything new, it's part of KVM/libvirt and more inherited than added.
The main reason I "don't see it coming" is that may create more problems than it solves.
To my understanding K8 is all about truly elastic workloads, including "mobility" to avoid constraints (including memory overcommit). Mobility in quotes, because I don't even know if it migrates containers or just shuts instances down in one place and launches them in another: migration itself has a significant cost after all.
We implemented live migrations for VMs quite some time ago. In practice that means that we are migrating qemu processes between pods on different nodes.
k8s does not dictate anything regarding the workload. There is just a scheduler which can or can not schedule your workload to nodes.
But if it were to migrate them (e.g. via CRIU for containers and "vMotion" for VMs) it would then to also have to understand (via KubeVirt), which devices are tied,
As far as I know pci passthrough and live migration do not mix well in general because neither oVirt nor OpenStack or other platforms can migrate the pci device state, since it is not in a place where it can be copied. Only SRIOV allows that via explicit unplug and re-plug.
because they use a device that has too big a state (e.g. a multi-gig CUDA workloads), a hard physical dependence (e.g. USB with connected devices) or something that could move with the VM (e.g. SR-IOV FC/NIC/INF with a fabric that can be re-configured to match or is also virtualized).
A proper negotiation between the not-so-dynamic physically available assets of the DC and the much more dynamic resources required by the application are the full scope of a virt-stack/k8 hybrid, encompassing a DC/Cloud-OS (infrastructure) and K8 (platform) aspects.
While KubeVirt does not offer everything which oVirt has at the moment, like Sandro indicated, the cases you mentioned are mostly solved and considered stable.
While I'd love to have that, I can see how that won't be maintained by anyone as a full free-to-use open-souce turn-key solution.
There are nice projects to install k8s easily, for installing kubevirt with its operator you just apply some manifests on the (bare-metal) cluster and you can start right away.
I can understand that a new system like k8s may look intimidating.
Best regards,
Roman
_______________________________________________
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-leave@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/
List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/OPAKEXBS4LZSG2HIU3AWGJJCLT22FFGF/