Description of problem: SSH service created outside the UI is not discoverable Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create a VM and start it 2. Manually create a Service exposing SSH server via port 22 for this VM 3. Actual results: copy ssh command is not available on vm details page available service is not identified as ssh service. Expected results: copy ssh command is available on vm details page available service is identified as ssh service using the port. Additional info: We identify the ssh service by it's name, instead we should look for a service that expose the standard SSH port (port 22)
Jens, Tal hi, We currently identify the service by it's name so a workaround is adjuasting the service name :-) we will need to fix in 4.10 too ( we will need to open a new bug on OCP -> kubevirt plugin for 4.10 )
example of a manually created service for port 22 for vm name-of-vm ``` apiVersion: v1 kind: Service metadata: name: some-ssh-service namespace: auto-test-ns spec: ports: - port: 22000 protocol: TCP targetPort: 22 selector: vm.kubevirt.io/name: name-of-vm type: NodePort ```
Jens hi in https://bugzilla.redhat.com/show_bug.cgi?id=2081671#c1 we proposed back porting the fix to 4.10 (we have the fix in 4.11) I prefer not to backport to 4.10 if we have a good workaround. Is it OK by you not to backport, and only fix for 4.11 ?
https://github.com/kubevirt-ui/kubevirt-plugin/pull/390 - merged upstream
Oh yes, absolutely fine for me, thanks!
There are still problems with the fix: 1. if the SSH is not enabled ever, SSH service created outside the UI is not visible 2. after the SSH service created outside the UI, then enable ssh access on UI, the ssh service is visible, but it still generate the default ssh service, then two ssh services available 3. if the ssh is enabled once, and then disable it. Kobi, do you prefer to address the problems in this bug or open new bugs?
(In reply to Guohua Ouyang from comment #7) > There are still problems with the fix: > 1. if the SSH is not enabled ever, SSH service created outside the UI is not > visible after fix the service should be discoverable when vm is running, it should not depend on "enabled" yes or not > 2. after the SSH service created outside the UI, then enable ssh access on > UI, the ssh service is visible, but it still generate the default ssh > service, then two ssh services available > 3. if the ssh is enabled once, and then disable it. > > Kobi, do you prefer to address the problems in this bug or open new bugs? From problem 1 it sound this bug is not fixed
Can't reproduce 1, 2 and 3. Is the created ssh service visible in the 'services' section? Can you please share the yaml used to generate the service?
Created attachment 1885901 [details] for problem #1, #2 In this video, the vm is freshed created and ssh is not enabled, create the ssh service via yaml, there is no ssh service available in vm details page. And then enable the ssh service, there are two ssh services visible.
Created attachment 1885902 [details] for #3 #3 is actually good, Seems I didn't write it down completely. After the ssh is enabled once for the VM, delete all ssh services and then create the ssh service via yaml, it works perfectly, only the ssh service created via yaml is visible.
Yesterday my pr about the ssh service gets merged to cover another bug (https://bugzilla.redhat.com/show_bug.cgi?id=2091940) The selector to use is slightly different. We'll use kubevirt.io/domain instead of vm.kubevirt.io/name as a selector if the VM has this label. If the VM does not have this label, we'll create it using the VM name. kubevirt.io/domain: ${VM_NAME}. So, in my env I used this yaml and it worked. Probably other prs solved the issue. apiVersion: v1 kind: Service metadata: name: some-ssh-service namespace: default spec: ports: - port: 22000 protocol: TCP targetPort: 22 selector: kubevirt.io/domain: rhel8-v4koffgl51qwyha7 type: NodePort
Sorry, can't edit the original message. The VMI should have the label kubevirt.io/domain in /metadata/labels and the VM should have the same label in /spec/template/metadata/labels
verified on v4.11.0-55
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 (Important: OpenShift Virtualization 4.11.0 Images security and bug fix 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:6526
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days