> On 22. 2. 2022, at 14:16, Roman Mohr <rm...@redhat.com> wrote: > > > > On Tue, Feb 22, 2022 at 1:25 PM Thomas Hoberg <tho...@hoberg.net > <mailto:tho...@hoberg.net>> wrote: > > On Tue, Feb 22, 2022 at 9:48 AM Simone Tiraboschi <stirabos(a)redhat.com > > <http://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.
That you can say about oVirt and Openstack and basically anyone else as well. The foundation for basically every virtualization features is always in qemu-kvm > > 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. Slowly but surely it is coming for other devices as well, it's in development for couple years now, and a topic for every KVMForum in the past ~5 years. > > 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. indeed! When speaking of kubevirt itself I really think it's "just" the lack of virt-specific UI that makes it look like a too low level tool compared to the oVirt experience. Openshift/OKD UI is fixing this gap...and there's always a long way towards more maturity and more niche features and use cases to add, sure, but it is getting better and better every day. Thanks, michal > > > 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 <mailto:users@ovirt.org> > To unsubscribe send an email to users-le...@ovirt.org > <mailto:users-le...@ovirt.org> > Privacy Statement: https://www.ovirt.org/privacy-policy.html > <https://www.ovirt.org/privacy-policy.html> > oVirt Code of Conduct: > https://www.ovirt.org/community/about/community-guidelines/ > <https://www.ovirt.org/community/about/community-guidelines/> > List Archives: > https://lists.ovirt.org/archives/list/users@ovirt.org/message/OPAKEXBS4LZSG2HIU3AWGJJCLT22FFGF/ > > <https://lists.ovirt.org/archives/list/users@ovirt.org/message/OPAKEXBS4LZSG2HIU3AWGJJCLT22FFGF/> > _______________________________________________ > Users mailing list -- users@ovirt.org > To unsubscribe send an email to users-le...@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/RXSWPU5MQHNRXBKOPWSDMJR4C6S2DPP5/
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@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/K3OX7XKQALX6W52RR4RP3ZR22LMT6GVY/
