Bug 1866095

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.