Description of problem: ssh related information is exposed for the Windows VMs created from the console which is not applicable for Windows OS. In Actions => Copy SSH command In virtual machine => Details => "SSH access" and "SSH over NodePort" In virtual machine => Scripts (Authorized SSH Key) Version-Release number of selected component (if applicable): OpenShift Virtualization 4.11.1 How reproducible: 100% Steps to Reproduce: 1. Create a virtual machine from the Windows template. 2. Navigate to the above-mentioned tabs and there is ssh related information. 3. Actual results: ssh related information displayed in the console for Windows VMs created from the template Expected results: ssh related information is not applicable to Windows OS and is not required. Additional info:
I talked about this topic with developer last year, the decision is keeping ssh option for windows because user can theoretically configure ssh on windows and also sysprep is keeping for linux.
I think it's misleading and I don't think ssh is the preferred method for remote access in Windows. It is not enabled/installed by default and the Kubernetes service just ends up in an inexistent port in the VM. The user may end up thinking that OpenShift Virt somehow enables this automatically in Windows. I am sure we will see cases around it from customers asking why it's not working :-)
Hi Fabian and Kobi, Would you like to comment in this bug?
@phoracek wdyt?
I tend to agree with Nijin - if this suggested SSH command would not work most of the time, I would not show it in the UI. It would only confuse users. If a user puts in the effort to configure SSH server on their Windows VM, they can use the generic Service UI to expose it to the outside.
(In reply to Guohua Ouyang from comment #3) > Hi Fabian and Kobi, > Would you like to comment in this bug? hiding ssh command for vms that do not use it makes sense for me too, Nijin hi, question: what should be the rule for hiding the ssh controllers and information ? a. template label (does not require vm to run), what label is best ? b. agent information (require vm to run) ? c. a different test ?
I agree that the best option is to identify the OS (I will let Dev decide how to identify it) and hide things that are irrelevant IF we have cases where we cannot identify the OS or we need a very quick solution, I am OK with just adding text like "(Windows only)" and "(Linux only)" next to the "Sysprep" and "SSH" correspondingly
VMs created from our templates don't have a common 'windows' or 'linux' label. While the templates refer to their specific OS: "vm.kubevirt.io/os: centos-stream8" or "vm.kubevirt.io/os: rhel8", VMs created from them don't inherit this label. Detecting it from a running OS sounds limiting. What about extending our templates so they set the general OS label on the VM+VMI itself. Then we can easily use it in the UI. If a VM was created without using templates, or is pre-dating the template update, we could then do what Ronen suggested in https://bugzilla.redhat.com/show_bug.cgi?id=2155403#c8.
The templates will fade away. @lyarwood do you plan VMs to have annotations or labels to reflect the expected guest os? I also like the idea of using the guest agent to identify the guest os. In the worst case, the UI would show the ssh option for a Windows VM which does not run the guest agent, e.g. during the first boot, which might be acceptable.
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 Virtualization 4.13.0 Images security, bug fix, and enhancement 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-2023:3205