7:23 p.m.
On 22. 2. 2022, at 14:16, Roman Mohr <rmohr(a)redhat.com> wrote:
On Tue, Feb 22, 2022 at 1:25 PM Thomas Hoberg <thomas(a)hoberg.net
<mailto:thomas@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(a)ovirt.org <mailto:users@ovirt.org>
To unsubscribe send an email to users-leave(a)ovirt.org
<mailto:users-leave@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/OPAKEXBS4LZ...
<https://lists.ovirt.org/archives/list/users@ovirt.org/message/OPAKEXBS4LZ...
_______________________________________________
Users mailing list -- users(a)ovirt.org
To unsubscribe send an email to users-leave(a)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/RXSWPU5MQHN...