Bug 2155403

Summary:	ssh related information displayed in OpenShift console for Windows VMs created from template
Product:	Container Native Virtualization (CNV)	Reporter:	nijin ashok <nashok>
Component:	User Experience	Assignee:	Dana Orr <dorr>
Status:	CLOSED ERRATA	QA Contact:	Guohua Ouyang <gouyang>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.11.1	CC:	dholler, fdeutsch, gouyang, hstastna, lyarwood, phoracek, rsdeor, yzamir
Target Milestone:	---
Target Release:	4.13.0
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-05-18 02:56:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description nijin ashok 2022-12-21 06:38:20 UTC

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:

Comment 1 Guohua Ouyang 2022-12-23 00:10:03 UTC

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.

Comment 2 nijin ashok 2022-12-23 02:52:15 UTC

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 :-)

Comment 3 Guohua Ouyang 2022-12-23 03:47:20 UTC

Hi Fabian and Kobi,
Would you like to comment in this bug?

Comment 4 Fabian Deutsch 2023-01-05 15:29:31 UTC

@phoracek wdyt?

Comment 5 Petr Horáček 2023-01-06 11:04:09 UTC

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.

Comment 6 Yaacov Zamir 2023-01-09 07:39:05 UTC

(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 ?

Comment 8 Ronen 2023-01-16 07:33:47 UTC

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

Comment 9 Petr Horáček 2023-02-14 09:12:13 UTC

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.

Comment 10 Dominik Holler 2023-02-14 12:11:34 UTC

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.

Comment 13 errata-xmlrpc 2023-05-18 02:56:36 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 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