My question is what is the difference between using virtctl expose vmi and oc expose virt_pod commands ? Are they both legit ways to create service for a VM Instance ? Would the exam question if any exists would require a specific method to use for creation of service for VMI?
chapter 03 slide 02
[student@workstation ~]$ virtctl expose vmi mariadb-server --name mariadb \ --type ClusterIP --port 3306 --target-port 3306 Service mariadb successfully exposed for vmi mariadb-server
chapter 03 slide 07
[user@host ~]$ oc expose ${POD} --name=vm1 \ --type=LoadBalancer --selector kubevirt.io/domain=vm1 --port=22 \ -o yaml --dry-run=client | tee service.yaml
To create a Kubernetes service, you must use the oc expose command with a virt-launcher pod. You cannot create a Kubernetes service by using the VM or VMI resources.
If you create a VM by using an instance type, then the kubevirt.io/domain label is not passed to the VMI and virt-launcher pod. For VMs that are created by using instance types, the vm.kubevirt.io/name label is applied to the virt-launcher pod.
Hello @Ravi_Shanker I think both serves the same purpose but AFAIK when KubeVirt starts a VM, it wraps it inside a virt-launcher pod. The VM's labels are automatically copied over to that pod.
This is a key detail. The virtctl expose vmi command is smart and it uses those labels to correctly create a Service for the VM without any extra effort on your part.
In contrast, if you try to use the regular oc expose command on the pod, you have to manually select it. This approach can be a problem because if the pod's labels ever change, your service might suddenly stop working.
The virtctl expose vmi vmi-name command uses all the VM labels to create a selector for the service. However still the VMI must match all the labels that a selector uses for the service to include the VMI because if a label on the VMI changes, then the VMI is no longer included in the services. But seems with the latest fix, it now uses the more stable label :
https://kubevirt.io/user-guide/release_notes/
Let me also contact the course developers to gain their perspective as well on this.
@Ravi_Shanker Also I want to add that in all the official doucmentation that I accessed I saw virtctl expose command - so I tend to feel that , it is the recommended approach.
@Ravi_Shanker Got an update that they wanted to show that you can do the same using oc expose command as well. So, I dont think in the exam it will depend on what you use unless the result is fulfilled.
Hello @Ravi_Shanker I think both serves the same purpose but AFAIK when KubeVirt starts a VM, it wraps it inside a virt-launcher pod. The VM's labels are automatically copied over to that pod.
This is a key detail. The virtctl expose vmi command is smart and it uses those labels to correctly create a Service for the VM without any extra effort on your part.
In contrast, if you try to use the regular oc expose command on the pod, you have to manually select it. This approach can be a problem because if the pod's labels ever change, your service might suddenly stop working.
The virtctl expose vmi vmi-name command uses all the VM labels to create a selector for the service. However still the VMI must match all the labels that a selector uses for the service to include the VMI because if a label on the VMI changes, then the VMI is no longer included in the services. But seems with the latest fix, it now uses the more stable label :
https://kubevirt.io/user-guide/release_notes/
Let me also contact the course developers to gain their perspective as well on this.
@Ravi_Shanker Also I want to add that in all the official doucmentation that I accessed I saw virtctl expose command - so I tend to feel that , it is the recommended approach.
@Chetan_Tiwary_ Thanks for the detailed response and explanation. I will await for your final update from course developers for all round perspective.
@Ravi_Shanker Got an update that they wanted to show that you can do the same using oc expose command as well. So, I dont think in the exam it will depend on what you use unless the result is fulfilled.
Red Hat
Learning Community
A collaborative learning environment, enabling open source skill development.