Closed vibhuti27 closed 1 month ago
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/
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.
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/ .
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
@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
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 is it possible that there is a firewall inside your guest blocking incoming traffic?
@orelmisan I don't think so. I checked the firewall rules couldn't find anything that could be blocking the incoming traffic
Hi @ormergi @orelmisan Can you please guide me on the issue?
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?
@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
Can you connect to the Linux Pod from the Windows guest?
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
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.
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.
Is the application configured to listen on the interface the guest gets from KubeVirt?
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
My knowledge of Windows is pretty basic. Please consider spinning up a well known service on the guest just to test the network connectivity.
@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.
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
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
Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen
.
Mark the issue as fresh with /remove-lifecycle rotten
.
/close
@kubevirt-bot: Closing this issue.
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:
virtctl version
): N/Akubectl version
): N/Auname -a
): N/A