On Tue, Feb 22, 2022 at 1:25 PM Thomas Hoberg <[email protected]> wrote:
> > 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 -- [email protected] > To unsubscribe send an email to [email protected] > 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/[email protected]/message/OPAKEXBS4LZSG2HIU3AWGJJCLT22FFGF/ >
_______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/RXSWPU5MQHNRXBKOPWSDMJR4C6S2DPP5/
