Bug 2028042 - Desktop viewer for Windows VM shows "no Service for the RDP (Remote Desktop Protocol) can be found"
Summary: Desktop viewer for Windows VM shows "no Service for the RDP (Remote Desktop P...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Console Kubevirt Plugin
Version: 4.9
Hardware: All
OS: Linux
high
urgent
Target Milestone: ---
: 4.10.0
Assignee: Yaacov Zamir
QA Contact: Guohua Ouyang
URL:
Whiteboard:
Depends On:
Blocks: 2028490 2029378
TreeView+ depends on / blocked
 
Reported: 2021-12-01 11:21 UTC by nijin ashok
Modified: 2023-09-15 01:17 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-03-10 16:31:07 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
desktop_view_delay (274.24 KB, image/gif)
2021-12-07 02:19 UTC, Guohua Ouyang
no flags Details
windows rdp connection works with the details shows on UI (710.05 KB, image/gif)
2021-12-09 03:42 UTC, Guohua Ouyang
no flags Details


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 10608 0 None Merged Bug 2028042: Fix NodePort RDP bug 2021-12-15 08:38:57 UTC
Red Hat Knowledge Base (Solution) 6574601 0 None None None 2021-12-09 14:15:27 UTC
Red Hat Product Errata RHSA-2022:0056 0 None None None 2022-03-10 16:31:20 UTC

Description nijin ashok 2021-12-01 11:21:14 UTC
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:

Comment 1 sgott 2021-12-01 13:06:37 UTC
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.

Comment 2 Dan Kenigsberg 2021-12-01 19:55:05 UTC
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

Comment 6 Germano Veit Michel 2021-12-02 04:03:44 UTC
Easily reproducible on my 4.9.8 cluster too. Same confusion.

Comment 7 Germano Veit Michel 2021-12-02 04:14:09 UTC
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`?)

Comment 8 Fabian Deutsch 2021-12-02 11:58:25 UTC
Moving this to UI per comment #5.

Comment 9 Petr Horáček 2021-12-02 12:28:50 UTC
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

Comment 10 Petr Horáček 2021-12-02 12:45:06 UTC
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

Comment 14 Guohua Ouyang 2021-12-07 02:19:22 UTC
Created attachment 1845008 [details]
desktop_view_delay

There are always a few seconds delay to show the RDP connection details, is it acceptable?

Comment 15 Yaacov Zamir 2021-12-07 05:31:04 UTC
> 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 ?

Comment 16 Guohua Ouyang 2021-12-08 08:26:18 UTC
(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

Comment 17 Petr Horáček 2021-12-08 08:29:19 UTC
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

Comment 18 Guohua Ouyang 2021-12-09 03:40:15 UTC
(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.

Comment 19 Guohua Ouyang 2021-12-09 03:42:12 UTC
Created attachment 1845386 [details]
windows rdp connection works with the details shows on UI

Comment 23 errata-xmlrpc 2022-03-10 16:31:07 UTC
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

Comment 24 Red Hat Bugzilla 2023-09-15 01:17:41 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days


Note You need to log in before you can comment on or make changes to this bug.