Software development has been gradually shifting from monolithic to distributed containerized applications. Such applications are composed of components referred to as micro services. With the increasing number of micro services, it becomes increasingly difficult to understand how all the components communicate. This is where Istio service mesh comes into play. Istio allows developers to manage and monitor network traffic between micro services and by providing features like mutual TLS, request retries or request circuit breaking. Vendoring these features from Istio helps keeping micro services focused on the actual application logic as they don't need to be implemented by the micro services. The IT industry has broadly adopted this architecture, but there are still plenty of legacy workloads running in virtual machines, which can't easily take the advantage of the features provided by service mesh. At least not until recently when KubeVirt introduced support for Istio service mesh. Attendees of this talk gain insight into the concept of the Istio sidecar proxy. A short demonstration showing typical use case of Istio service mesh -- canary deployment -- is presented. Next, this talk explains subtle differences of network traffic routing between regular Kubernetes pods and containerized KubeVirt virtual machines, leading to the challenges that these differences pose for traffic proxying. Finally, the changes necessary to support Istio for KubeVirt virtual machines are explained and the resulting functionality presented using the same scenario, but with the workload running in virtual machines instead of Kubernetes Pods. The takeaway of this talk is understanding of routing concepts behind Istio proxy sidecar with regular Kubernetes pods as well as with containerized KubeVirt virtual machines. Audience will have a chance to observe typical use case of Istio with both pods and virtual machines and get insight into the necessary changes that made this possible.