Hide Forgot
Description of problem: The desktop viewer for Windows VM shows the below error even when the service for rdp exists. ~~~ This is a Windows virtual machine but no Service for the RDP (Remote Desktop Protocol) can be found. For better experience accessing Windows console, it is recommended to use the RDP. To do so, create a service: exposing the 3389/tcp port of the virtual machine using selector: vm.kubevirt.io/name: win10-imaginative-tortoise Example: virtctl expose virtualmachine win10-imaginative-tortoise --name win10-imaginative-tortoise-rdp --port [UNIQUE_PORT] --target-port 3389 --type NodePort Make sure, the VM object has spec.template.metadata.labels set to vm.kubevirt.io/name: win10-imaginative-tortoise ~~~ The service is already available. ~~~ oc get svc win10-imaginative-tortoise-rdp -o yaml |yq -y '.spec' clusterIP: 172.30.223.43 clusterIPs: - 172.30.223.43 externalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - nodePort: 32144 port: 8555 protocol: TCP targetPort: 3389 <<<<<<<<<<< selector: kubevirt.io/domain: win10-imaginative-tortoise os.template.kubevirt.io/win10: 'true' vm.kubevirt.io/name: win10-imaginative-tortoise <<<<<<<< workload.template.kubevirt.io/desktop: 'true' sessionAffinity: None type: NodePort ~~~ In the browser console, I can see below error message. ~~~ Node IP (launcherpod.status.hostIP) is not yet known for NodePort RDP Service: {kind: 'Service', apiVersion: 'v1', metadata: {…}, spec: {…}, status: {…}} apiVersion: "v1" kind: "Service" metadata: {name: 'win10-imaginative-tortoise-rdp', namespace: 'nijin-cnv'' ..... ~~~ Looks like it's unable to find "launcherpod.status.hostIP"? The status for the pod does show the "hostIP" address. ~~~ oc get pods virt-launcher-win10-imaginative-tortoise-lpwbl -o yaml|yq -y '.status.hostIP' 10.74.130.149 ~~~ IIUC, it matches the ownerReferences.uid of the pod with the VMI metadata.uuid to find the launcher pod(?). This is also correct here. ~~~ oc get vmi win10-imaginative-tortoise -o yaml |yq -y '.metadata.uid' d4a3dfb7-7447-4aee-80ae-1c32a3d863dd oc get pods virt-launcher-win10-imaginative-tortoise-lpwbl -o yaml|yq -y '.metadata.ownerReferences[0].uid' d4a3dfb7-7447-4aee-80ae-1c32a3d863dd ~~~ Not sure why wee are getting error "(launcherpod.status.hostIP) is not yet known for NodePort RDP Service". Version-Release number of selected component (if applicable): v4.9.0 How reproducible: 100% Steps to Reproduce: 1. Created a Windows VM with openshift console. 2. Created a service for rdp service. virtctl expose virtualmachine win10-imaginative-tortoise --name win10-imaginative-tortoise-rdp --port 8555 --target-port 3389 --type NodePort 3. Tried to access the console of the VM (console => Desktop viewer). With the default Openshift network, getting above error. I was able to manually connect access rdp console using nodeip:nodeport. Actual results: Desktop viewer for Windows VM shows "no Service for the RDP (Remote Desktop Protocol) can be found" Expected results: Since the service is already created, I expect it to provide a console.rdp file. Additional info:
Hi nijin, we're missing some information in order to help you. Can you provide the VM spec, the launcher pod and node port specs? We can't tell from what's provided so far if this is a misconfiguration or a bug.
Our docs are quite explicit about RDP requiring a secondary (Layer-2) network interface, not mentioning `virtctl expose`. https://docs.openshift.com/container-platform/4.9/virt/virtual_machines/virt-accessing-vm-consoles.html#virt-vm-rdp-console-web_virt-accessing-vm-consoles @phoracek do you know/recall why? RDP over pod network seems like a valid request and it is mentioned upstream https://kubevirt.io/user-guide/virtual_machines/service_objects/#expose-virtualmachineinstance-as-a-loadbalancer-service
Easily reproducible on my 4.9.8 cluster too. Same confusion.
Can we please also fix this "Layer 2" NIC description? This does not make much sense from a networking perspective. Any vNIC operates at the link layer, it doesn't matter what its backend is connected to. NICs are by definition operating at Layer 1 and Layer 2 of OSI Model. If it ends up encapsulated into the SDN, thats another matter. I suggest to specify it more clearly, maybe like "A virtual networking interface of type `bridge`, `macvlan`, `host-device`.... (not `masquerade`?)
Moving this to UI per comment #5.
I think we have multiple issues here: 1) The documentation of RDP access is confusing. I will open a BZ for that 2) The UI is unable to recognize the Service, even after it was created following steps provided by the UI. This BZ should be used for that 3) "Layer-2" is not describing well what we do there. I will open a separate BZ for that 4) In customer's cluster, it seems that NodePort with RDP is not reachable from the outside. This is being looked into on the ticket. I think we could try using port-forwarding to get pass this. I'll try to test it and if it works, provide a guide on the ticket
It seems that the UI is expecting a regular ClusterIP service to appear, but the guide describes how to create NodePort. When I created a regular service for my VM, the dialog have appeared and I was able to download the rdp file. However, since it was using the cluster IP, it was not usable. virtctl expose vm win10-healthy-meerkat --port=3389 --name=rdp-service
Created attachment 1845008 [details] desktop_view_delay There are always a few seconds delay to show the RDP connection details, is it acceptable?
> There are always a few seconds delay to show the RDP connection details, is it acceptable? no it's not :-) we need to fix it or add some help text that say somthing like ? "please wait = checking for RDP server" ? if we can't find the real problem Tal hi, This is a hign priority bug, can we push this fix and then open a new bug to fix this message ?
(In reply to Yaacov Zamir from comment #15) > > There are always a few seconds delay to show the RDP connection details, is it acceptable? > > no it's not :-) we need to fix it or add some help text that say somthing > like ? "please wait = checking for RDP server" ? if we can't find the real > problem > > > Tal hi, > This is a hign priority bug, can we push this fix and then open a new bug to > fix this message ? Move this to verified as it shows the RDP connection details after a few seconds. Opened a new bug to track the delay issue: https://bugzilla.redhat.com/show_bug.cgi?id=2030203
Guohua, did you try connecting using the shown details? Since this did not work at all before, I wonder if the RDP connection through UI functions as expected. Thanks in advance
(In reply to Petr Horáček from comment #17) > Guohua, did you try connecting using the shown details? Since this did not > work at all before, I wonder if the RDP connection through UI functions as > expected. Thanks in advance I've tested it in the past，it worked. I just managed to verified it on 4.10, it still works.
Created attachment 1845386 [details] windows rdp connection works with the details shows on UI
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: OpenShift Container Platform 4.10.3 security update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:0056