At the end - KubeVirt provides you a way to run a VM as a custom resource in an app on k8s (virt-launcher), while Virtlet provides a way to run VM as first class cluster citizen, as a pod, with the same interfaces as for other pods (so you can use kubectl logs, kubectl attach -it, as with other "normal" (docker image based) pods).
ok, with windows vm you will see in kubectl logs only cloud init logs as thats the only part which is using serial console to output something :P
with other types of vm images (based on linux, bsd or unikernels) you would probably appreciate more possibility to use kubectl attach -it, or kubectl logs ;)
We don't have every controller type available in KubeVirt, but we have for instance a VirtualMachineReplicaSet and an OfflineVirtualMachine (soon renamed to StatefulVirtualMachine): https://www.kubevirt.io/user-guide/#/workloads/controllers/R.... A VirtualMachineStatefulSet will definitely be added. Others will be added on demand.
Regarding disk: I am not sure why you think that there are special configurations necessary on the images to run a vm on KubeVirt. Maybe you can explain that in more detail. It is one of the core use-cases that you simply start your already existing vm without modifications on the images in KubeVirt. We support different volume types, including a RegistryDisk. See https://www.kubevirt.io/user-guide/#/workloads/virtual-machi... for further details.
And of course we support cloud-init: https://www.kubevirt.io/user-guide/#/workloads/virtual-machi....
It is true that we do not integrate as far with "kubectl" like virtlet does. We have our own "virtctl" tool which provides virtualization related commands (e.g. "virtctl console", "virtctl vnc", ...). Some of them replacing a missing kubectl pieces, some of them adding virtualization specific commands. Having the deep integration is indeed nice. I just want to add that solely depending on "kubectl" is a two-edged sword. For some vms things work, for others not. There is a good chance that people have to modify their images to properly integrate with "kubectl" in the mentioned ways. That is exactly what we did not want.
Personally I think that there are differences between pods and virtual machines (arguably varying depending on what you do with your workloads). Integrating where things are equal and extending otherwise is a good thing. It allows very natural interactions.
I would be careful with saying that one or the other project allows running vms more as "first class citizen" in the cluster than the other. We could probably argue about that forever.
If this lands, then KubeVirt would get that support "for free" (tm)
I'd have for someone to do a kubectl delete pod --all thinking they are only deleting stateless apps and getting rid of VMs too.
Edit: disclaimer: my company does RancherVM.
We run a public cloud largely based on OpenStack components. While OpenStack can be daunting, using a configuration manager like Ansible makes any kind of deployments a lot simpler and reusable. We use Ansible internally to deploy Kubernetes to deploy new versions of OpenStack.
Tutorial[0] on how to use Ansible in combination with OpenStack.
[0]: https://fuga.cloud/academy/tutorials/deploying-owncloud-on-f...
Also, how does a Kubernetes-managed VM compare to a plain VM from, say, AWS EC2? I imagine it's a little less efficient, since the situation I'm imagining involves various VMs running a Kubernetes pod running the VM, but I may have this all wrong.
