Unable to connect to Windows VM (running in virt launcher pod) from a linux pod in the same namespace and cluster

[vibhuti27]

What happened: A clear and concise description of what the bug is.

What you expected to happen: A clear and concise description of what you expected to happen.

How to reproduce it (as minimally and precisely as possible): Steps to reproduce the behavior.

Additional context: Add any other context about the problem here.

Environment:

• KubeVirt version (use virtctl version): N/A
• Kubernetes version (use kubectl version): N/A
• VM or VMI specifications: N/A
• Cloud provider or hardware configuration: N/A
• OS (e.g. from /etc/os-release): N/A
• Kernel (e.g. uname -a): N/A
• Install tools: N/A
• Others: N/A

[orelmisan]

Hello @vibhuti27, thank you for your interest in KubeVirt. It is unclear from the subject what exactly is the action that cannot be performed, could you please elaborate?

Providing additional details such as VM manifest used, K8s and KubeVirt versions could help as well.

KubeVirt's user guide has a section on Windows VMs: https://kubevirt.io/user-guide/virtual_machines/windows_virtio_drivers/

[vibhuti27]

Hi @orelmisan , I have created a Windows Server 2019 VM using a qcow2 image in the EKS Cluster VM Manifest Used:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: win-off
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  running: true
  template:
    metadata:
      labels:
        kubevirt.io/domain: testpvc
    spec:
      domain:
        cpu:
          cores: 16
        devices:
          disks:
          - bootOrder: 1
            disk:
              bus: sata
            name: cdromiso
          - bootOrder: 2
            disk:
              bus: sata
            name: harddrive
          - bootOrder: 3
            cdrom:
              bus: sata
            name: virtiocontainerdisk
        machine:
          type: q35
        resources:
          requests:
            memory: 32G
      volumes:
      - name: cdromiso
        persistentVolumeClaim:
          claimName: testpvc
      - name: harddrive
        persistentVolumeClaim:
          claimName: win-off
      - containerDisk:
          image: quay.io/kubevirt/virtio-container-disk
        name: virtiocontainerdisk       

I can ping from one pod to the virt-launcher pod and vice-versa but curl and telnet commands give Connection Timed Out.

[orelmisan]

Thank you for sharing the VM manifest. It seems that the pod network and network interface are not defined. Please see https://kubevirt.io/user-guide/virtual_machines/interfaces_and_networks/ .

[vibhuti27]

HI @orelmisan , Thanks for the quick response. I tried modifying the manifest file with networks and interfaces, but i faced a similar issue

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: win-off
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 20Gi
---
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: testvm
spec:
  running: true
  template:
    metadata:
      labels:
        kubevirt.io/domain: testpvc
    spec:
      domain:
        cpu:
          cores: 16
        devices:
          interfaces:
          - name: default
            masquerade: {}  
          disks:
          - bootOrder: 1
            disk:
              bus: sata
            name: cdromiso
          - bootOrder: 2
            disk:
              bus: sata
            name: harddrive
          - bootOrder: 3
            cdrom:
              bus: sata
            name: virtiocontainerdisk
        machine:
          type: q35
        resources:
          requests:
            memory: 32G
      networks:
      - name: default
        pod: {} # Stock pod network
      volumes:
      - name: cdromiso
        persistentVolumeClaim:
          claimName: testpvc
      - name: harddrive
        persistentVolumeClaim:
          claimName: win-off
      - containerDisk:
          image: quay.io/kubevirt/virtio-container-disk
        name: virtiocontainerdisk

[ormergi]

@vibhuti27 Hi, is the guest interface enabled? Kubevirt set the domain with virtio driver for the network interface by default, if the guest doesnt have the driver installed networking may not work. Could you try different driver, e1000, and see if this is the issue?

spec:
  domain:
    devices:
       interfaces: 
       - name: default
         masqurade: {}
         model: e1000

Alternatively, install virtio drivers https://kubevirt.io/user-guide/virtual_machines/windows_virtio_drivers

[vibhuti27]

Hi @ormergi , I have the virtio drivers already installed in the VM. Also, ping and internet connectivity is there just that telnet and curl give a timeout.

[orelmisan]

@vibhuti27 is it possible that there is a firewall inside your guest blocking incoming traffic?

[vibhuti27]

@orelmisan I don't think so. I checked the firewall rules couldn't find anything that could be blocking the incoming traffic

[vibhuti27]

Hi @ormergi @orelmisan Can you please guide me on the issue?

[orelmisan]

Hi @ormergi , I have the virtio drivers already installed in the VM. Also, ping and internet connectivity is there just that telnet and curl give a timeout.

@vibhuti27 Are you trying to connect to this VM from within the cluster? or from outside of it?

[vibhuti27]

@orelmisan within the cluster. I have created a Linux pod inside the same cluster and same namespace and i am trying to telnet and curl from the linux pod to the windows vm

[orelmisan]

Can you connect to the Linux Pod from the Windows guest?

[vibhuti27]

I see a connection refused message instantly when trying to connect to linux pod from windows guest .. probably because the port 8080 is not exposed ? i was doing curl http://virt-launcherip(vmi ip):8080

[orelmisan]

Are there services listening on both sides? Can you ping the Linux pod from the windows guest? Please note that with masquerade binding, the guest is behind NAT.

[vibhuti27]

I have the service listening on just the Windows guest side since i have the application running in windows VM on port 8080 and when we want to access it from another port. Ping is happening from Linux to Windows and vice versa also.

[orelmisan]

Is the application configured to listen on the interface the guest gets from KubeVirt?

[vibhuti27]

hmm, I am not sure about it. Can you please tell me how would i check and also how can i configure my java application to listen on an interface? I just did a netstat -a and saw that the port 8080 was on Listening mode

[orelmisan]

My knowledge of Windows is pretty basic. Please consider spinning up a well known service on the guest just to test the network connectivity.

[ormergi]

@vibhuti27 did you manage to make it work? can we close this issue?

Just to make sure, you should use the VM pod IP (virt-launcher) in to access the service that runs in the guest. As Orel mentioned, you can run some well known app just to verify that it works, such as nginx, httpbin.

[kubevirt-bot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

/lifecycle stale

[kubevirt-bot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten. Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

/lifecycle rotten

[kubevirt-bot]

Rotten issues close after 30d of inactivity. Reopen the issue with /reopen. Mark the issue as fresh with /remove-lifecycle rotten.

/close

[kubevirt-bot]

@kubevirt-bot: Closing this issue.

In response to [this](https://github.com/kubevirt/kubevirt/issues/11111#issuecomment-2250005074): >Rotten issues close after 30d of inactivity. >Reopen the issue with `/reopen`. >Mark the issue as fresh with `/remove-lifecycle rotten`. > >/close Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes-sigs/prow](https://github.com/kubernetes-sigs/prow/issues/new?title=Prow%20issue:) repository.