Bug 1866095 - RDP session cannot be re-established
Summary: RDP session cannot be re-established
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Networking
Version: 2.4.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
: 4.10.0
Assignee: Petr Horáček
QA Contact: Yossi Segev
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-08-04 20:09 UTC by Yossi Segev
Modified: 2023-09-15 00:46 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-01-06 13:39:20 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
rdp-win-nfs-rwo-dv.yaml (380 bytes, text/plain)
2020-08-04 20:09 UTC, Yossi Segev
no flags Details
valid-screen (22.71 KB, image/png)
2020-08-04 20:24 UTC, Yossi Segev
no flags Details
wait-local-session-mngr (22.99 KB, image/png)
2020-08-04 20:26 UTC, Yossi Segev
no flags Details
rdp-win-hpp-rwo-dv.yaml (397 bytes, text/plain)
2020-08-04 20:36 UTC, Yossi Segev
no flags Details
rdp-vmi.yaml (6.37 KB, text/plain)
2020-08-05 18:38 UTC, Yossi Segev
no flags Details

Description Yossi Segev 2020-08-04 20:09:58 UTC
Created attachment 1710419 [details]
rdp-win-nfs-rwo-dv.yaml

Description of problem:
When disconnecting an RDP session to a Windows VM, a new session cannot be opened.


Version-Release number of selected component (if applicable):
OCP: 4.5.4
CNV 2.4.0


How reproducible:
Always


Steps to Reproduce:
Happens on my IPI cluster.
* In order to deploy a Windows VM - it might be necessary to deploy a cluster with size values which are not the minimal. I deployed a cluster with size virt.w1.xlarge (vCPUs=4, RAM=16Gio, Root Disk=80GB).
* Makre sure to deploy all needed resources - DataVolume, VM and service - in the same namespace.

1. Apply DataVolume (DV spec yaml attached):
$ oc apply -f rdp-win-hpp-rwo-dv.yaml
* Please use "oc apply" rather than "oc create", because using this command adds annotations to the resource spec, and the annotations are suspected to be part of the cause for this bug.

2. Create a Windows VM *using the UI*:
 a. Create a Windows VM:
 Workloads -> Virtualization -> Create Virtual Machine (button) -> New with Wizard

 b. Change the Project to be the namespace you want to create everything in (the same one where you already created the DV in).

 c. General:
 Source: Disk
 Operating System: Microsoft Windows Server 2016
 Flavor: Medium
 Workload Profile: Server

 d. Networking: Keep the default.

 e. Storage:
 - Press "Add Disk" button:
    Source: Attach Disk
    PVC: The PVC that was created as part of the DV (the PVC and DV should have the same name).
    Interface: sata
 - Boot Source: disk-0 (the name of the storage disk you have just created).

 f. Advanced: Keep the default for both "Cloud-init" and "Virtual Hardware".

 g. Review:
 Check "Start virtual machine on creation" box.
 Press "Create Virtual Machine" button.

3. Create a service to expose the VM via RDP port:
 $ virtctl expose virtualmachine win16-rdp-sata-vm --name rdp-16-sata-svc --port 12303 --target-port 3389 --type NodePort

4. Enable X11 forwarding on the cluster, to enable the the Remote Desktop UI to run on your computer, while the Remote Desktop client runs on the cluster:
Run the following commands on the cluster executor:
  $ sudo vi /etc/ssh/sshd_config:
   AllowAgentForwarding yes
   AllowTcpForwarding yes
   GatewayPorts yes
   X11Forwarding yes
   #X11DisplayOffset 10
   X11UseLocalhost no
   #PermitTTY yes

 $ sudo systemctl restart sshd
 $ sudo yum install xauth -y
 $ sudo touch ~/.Xauthority
 $ sudo chmod 777 ~/.Xauthority

 Login again to the cluster, and this time add “-Y” to the SSH login command.

5. In the UI (in the Virtual Machine) - go to Console -> Desktop Viewer (the button maybe on "VNC Console" by default) -> Launch Remote Desktop
 A console.rdp file is downloaded to your computer.

6. Copy the RDP file to the cluster (e.g. using scp command).

7. Install Remmina client in your cluster:
 $ sudo yum install -y remmina

8. Run Remmina in the cluster:
 $ remmina -c console.rdp
It might take a while (between seconds to minutes), and then an RDP viewer opens on your computer.
Also - the process of establishing the connection might include failure and error messages, but ends up with the successful RDP viewer. You should a Windows desktop screen like in the attached "valid-screen_attachment.

9. Close the RDP Window, and stop the remmina process in your cluster (by pressing Ctrl+C).

10 Repeat step 8.


Actual results:
<BUG> The attempt to obtain RDP session doesn't end with the expected Windows screen.
After a few minutes (could take up to 10 minutes) the RDP Window closes, and the folowing line appears in the remmina output (in your cluster):
[15:47:33:647] [16573:16613] [INFO][com.freerdp.core] - ERRINFO_LOGOFF_BY_USER (0x0000000C):The disconnection was initiated by the user logging off their session on the server.
Please note that progress screen like the attached "wait-local-session-mngr" image is not an indication of a successful RDP session - you should wait for the Windows desktop screen.


Expected results:
Windows VM is accessible via RDP, like at the end of step 8.


Additional info:
When the bug occurs - try the following:
1. Remove the annotations from the DV:
 $ oc edit dv win-16-hpp-rwo
 Search for "annotations" and delete this key and all its values, and save the new DV spec.
 Repeat step 8.

If that doesn't work - restart the VMI:
 $ virtctl restart <vm-name>
And then repeat step 8.

This might look like a duplication of bug#1784856, but it is probably not, because I used the same configuration Ruty used when running the successful scenario that led to closing that bug.

Comment 1 Yossi Segev 2020-08-04 20:24:29 UTC
Created attachment 1710423 [details]
valid-screen

Comment 2 Yossi Segev 2020-08-04 20:26:59 UTC
Created attachment 1710424 [details]
wait-local-session-mngr

Comment 3 Yossi Segev 2020-08-04 20:28:50 UTC
Thank you Ruty (Ruth Netser) for helping me investigating this bug!

Comment 4 Yossi Segev 2020-08-04 20:36:41 UTC
Created attachment 1710426 [details]
rdp-win-hpp-rwo-dv.yaml

Comment 6 sgott 2020-08-05 15:30:26 UTC
Unfortunately I suspect the issue you're experiencing has nothing at all to do with OpenShift Virtualization. The RDP service your client is connected to is running inside your VM. There is one small touch-point here in that our infrastructure does need to connect external traffic to ports on your VM (depending on your network interface). However, that appears to be working correctly as evidenced by the fact that you could connect in the first place.

I've re-assigned this BZ to the networking component for them to take a look. In the meantime, it might help if you included the VM's manifest.

Comment 7 Yossi Segev 2020-08-05 18:38:10 UTC
Created attachment 1710563 [details]
rdp-vmi.yaml

Comment 8 Yossi Segev 2020-08-05 18:40:15 UTC
Thanks Stu.
Actually I wasn't sure which component to address this bug to - virt, networking or even storage (as the annotations in the DV affect this bug too), so I placed my bets on virt.
Anyway, I attached the VMI spec (rdp-vmi.yaml).

Comment 10 Yossi Segev 2020-09-02 09:15:47 UTC
This issue is currently checked by the CNV networking devel people.
I will update according to their findings.

Comment 11 Yossi Segev 2020-09-03 11:02:19 UTC
Something I should check to Or Mergi's request, when I get back to this bug:
Check if this happens when gracefully logging out of the VM, instead of breaking the Remmina session with Ctrl+C.

Comment 12 Yossi Segev 2020-10-11 14:56:36 UTC
(In reply to Yossi Segev from comment #11)
> Something I should check to Or Mergi's request, when I get back to this bug:
> Check if this happens when gracefully logging out of the VM, instead of
> breaking the Remmina session with Ctrl+C.

The flow Or suggested works:
- Graceful log out (Windows start Menu -> Administrator -> Logout).
- After logout is completed - kill the remmina process in the cluster (using ctr+C).
- Run "remmina -c console.rdp" in the cluster again
A new and accessible RDP session starts.

Comment 13 Petr Horáček 2020-10-22 07:51:11 UTC
Let's see if we can make the process easier for users.

Comment 14 Petr Horáček 2021-01-06 11:08:24 UTC
Postponing for low capacity and severity of this issue.

Comment 17 Petr Horáček 2022-01-06 13:39:20 UTC
This seems to be a bug of the RDP client, not of KubeVirt. Feel free to reopen if you have any new data proving otherwise.

Comment 18 Red Hat Bugzilla 2023-09-15 00:46:02 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.