Hi Andre,
Is there someone who has done an NON PERSISTANT VDI over oVirt using kubevirt (on OKD) as the infraestructure for vm's?
We plan to do a 1.000.000 concurrent users deployment...
I am working on KubeVirt. I can't tell you how the integration in oVirt works in detail and which capabilities you inherit from normal RHV flows, but I can tell you a little bit about this from the kubevirt and openshift perspective.
I think that you will need a bunch of openshift clusters (10+) to cope with that number of VMs/Pods. Also keep in mind that you will have to use for VDI something like citrix, windows remote desktop or so on. KubeVirt does not support spice, just in case that this was your target.
Others can probably tell you more.
In terms of the oVirt-KubeVirt integration, please note that there's no mapping to VM pools.
I imagine that in oVirt you would probably create VM pool(s) for this - but doing that won't result in having a corresponding entity in KubeVirt. And it wouldn't work the other way around - having ReplicateSet/StatefulSet in KubeVirt will not result in a VM pool on the oVirt side but rather in individual VMs.
So while the integration may allow you to do user management related things from within oVirt, it won't allow you to do those that are VM pool related like defining "Maximum number of VMs per user". Other VM pool related features may also not be available - either basic ones like assigning a VM to a user and starting the VM when user "takes" a VM from the VM pool or more advanced ones like template versions (automatic update of VMs in the pool to the latest version of the template that the pool is based on).
There are other aspects in KubeVirt that may be relevant in this context like (Roman/Fabian, please keep me honest as these may have changed):
* The lack of thin-provisioning of VMs on top of template - pool VMs are not just set with qcow volumes on top of the template's volumes but rather each VM has its own isolated volumes. So with that number of VMs, you may want to make sure the storage device(s) you use provides decent deduplication capabilities.
* The lack of memory overcommit management - without a tool like MOM that controls KSM and ballooning you may need more hardware (memory) than you would have probably needed with oVirt for this.
* The lack of console features - it's not just about SPICE not being supported but also the 'console-disconnect-action' setting. So the console you get from oVirt to VMs that are running in KubeVirt may not be sufficient.
So in terms of the oVirt-KubeVirt integration I'd say that in this context you may get user management capabilities to some degree and the ability to manage VMs that spread across various KubeVirt/OKD clusters from a single place, but there may be other aspects (depending on your needs) that you may need to consider.
_______________________________________________
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/2XATWOFBPPZWCUUYFG2QTJ25VDV6WGOW/