Document URL: https://access.redhat.com/articles/3500741 Section Number and Name: Access the virtual machine The virtctl expose command forwards a virtual machine instance port to a node port and creates a service for enabled access. The following example creates the fedora-vm-ssh service which forwards port 22 of the fedora-vm virtual machine to port 20022 on the node: virtctl expose vm fedora-vm --port=20022 --target-port=22 --name=fedora-vm-ssh After the service has been created, you can access the virtual machine instance via SSH using the ipAddress of the node. Login to the virtual machine instance: ssh username@<node IP> -p 20022 Describe the issue: I think the above part for virtctl expose is not accurate enough. Suggestions for improvement: 1. It is better to update the cmd to virtctl expose vm fedora-vm --port=20022 --target-port=22 --node-port=30001 --name=fedora-vm-ssh --type=NodePort --port 20022 --> this port is just for accessing the vm via ClusterIP/LoadBalancer type --node-port 30001 --> this port is the one for accessing the vm via NodePort 2. The NodePort range is 30000-32767, so we the port 20022 is out of the range if we want to set it as a nodeport, or we can add a note for the nodeport range. Maybe we can update to: Access the virtual machine The virtctl expose command forwards a virtual machine instance port to a node port and creates a service for enabled access. The following example creates the fedora-vm-ssh service which forwards port 22 of the fedora-vm virtual machine to port 30001 on the node: **Note:** NodePorts are in the 30000-32767 range by default virtctl expose vm fedora-vm --port=20022 --target-port=22 --node-port=30001 --name=fedora-vm-ssh --type=NodePort After the service has been created, you can access the virtual machine instance via SSH using the ipAddress of the node. Login to the virtual machine instance: ssh username@<node IP> -p 30001 Additional information:
On my environment, after running the following command : virtctl expose vm fedora-vm --port=20022 --target-port=22 --node-port=30001 --name=fedora-vm-ssh --type=NodePort I still need to ssh to port 20022 with this command instead of 30001 : ssh username@<node IP> -p 20022
Hi, Jean-Francois Saucier Seems I can't reproduce the issue you mentioned. Only port 30001 works for nodeIP. $ oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE fedora-svc NodePort 172.30.72.181 <none> 20022:30001/TCP 3s $ ssh fedora.246.58 -p 20022 ssh: connect to host 10.8.246.58 port 20022: No route to host $ ssh fedora.246.58 -p 30001 The authenticity of host '[10.8.246.58]:30001 ([10.8.246.58]:30001)' can't be established. ECDSA key fingerprint is SHA256:5jlzvgFNwHvgZZtZHoB5vpQ2UBuxL+TiBBv2DlrZlzg. ECDSA key fingerprint is MD5:db:f4:cb:12:e5:91:55:96:f8:f4:58:d5:8e:a5:d6:ab. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '[10.8.246.58]:30001' (ECDSA) to the list of known hosts. fedora.246.58's password: [fedora@vmi-fedora ~]$ Could you please kindly check that you are using the correct NodeIP? If the port 20022 works, I think maybe you are using the clusterIP instread of nodeIP.
Hi Yan, You are absolutely right, I was using the ClusterIP in my previous comment, you can disregard it. Using the correct NodeIP, the port is effectively 30001.
Hi, thanks for raising the bug. Please check my revision to make sure it is correct: https://github.com/openshift/openshift-docs/blob/f6f36503f3d94b8fbc8f8db3ac2564d930e17b0a/modules/cnv_accessing_vmi_ssh.adoc
Hi, The doc LGTM. Thanks
I think that `--node-port` should be removed immediately. That was for sure an unintended diversion from `kubectl expose`. `kubectl` uses --port in combination with --type=NodePort. `--node-port` does not exist there. We want it to work the same way.
Roman - >>>> Do I understand correctly that this: $ virtctl expose vm fedora-vm --port=20022 --target-port=22 --node-port=30001 --name=fedora-vm-ssh --type=NodePort $ ssh username@<node IP> -p 30001 >>>> should be changed to this: $ virtctl expose vm fedora-vm --port=20022 --target-port=22 --name=fedora-vm-ssh --type=NodePort $ ssh username@<node IP> -p 30001 >>>> ?
@Roman @Pan --node-port is not a required parameter here, a random nodeport will be assigned to the service (30000-32767) when remove the --type=NodePort in the cmd, if we do that, then I think we need explain why we use the random port for "ssh username@<node IP> -p $RandomPort"
So what I am trying to say is this, that on kubectl it works like this: $ kubectl expose pod mypod --port=20022 --target-port=22 --name=myservice --type=NodePort whereas for virtctl you would have to do: $ kubectl expose pod mypod --node-port=20022 --target-port=22 --name=myservice --type=NodePort We did not want to introduce a different syntax for virtctl than for kubectl. We have a bug here in virtctl.
Ok, so if the bug is in virtctl then IIUC, I should keep the current syntax (from my commit in Comment 4) until that bug is fixed. Correct me if I am wrong, but I'll move this to ON_QA in the meantime.
I will open another bug for tracking the --node-port problem since this bug is a Doc bug. @Pan, IMO, I think you could update the doc as Roman suggested. As I said in #Comment8, --node-port is not a required parameter, you could remove --node-port in the doc and add a line to explain how we can get the random node port the service acquired. WDYT?
I think this is targeted for 1.3
Yan, unfortunately I'm not sure I understand. Are you saying that I should remove both "--node-port" and "--type=NodePort"? This is based on Comment #8 where you mention both arguments. Or should I just remove "--node-port"? And is this basically the workaround we're discussing?: 1. run virtctl command (no --node-port) 2. run command to figure out what port virtctl acquired (this seems clunky to me, if so). something like "grep virtctl /etc/services"? Not sure what the preferred command is. 3. ssh username@<node IP> -p <port from step 2> Thanks :)
Hi, Pan I think you almost get it. Removing the "--node-port" is enough, we need to keep the "--type=NodePort" since we are exposing a NodePort type service. Hope below can help you to understand it: Access the virtual machine The virtctl expose command forwards a virtual machine instance port to a node port and creates a service for enabled access. The following example creates the fedora-vm-ssh service which forwards port 22 of the fedora-vm virtual machine to a node port on the nodes: virtctl expose vm fedora-vm --port=20022 --target-port=22 --name=fedora-vm-ssh --type=NodePort After the service has been created, you can check the service and access the virtual machine instance via SSH using the ipAddress of the node. oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE fedora-vm-ssh NodePort 172.30.117.206 <none> 22:32551/TCP 6s Login to the virtual machine instance: ssh username@<node IP> -p 32551
Above part should update to: oc get svc NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE fedora-vm-ssh NodePort 172.30.99.22 <none> 20022:32551/TCP 6s
Hi, I created a pull request against master (https://github.com/kubevirt/kubevirt/pull/1716) which should remove the differences between `kubectl expose` and `virtctl expose`. @Fabin would we want to backport this? It is not the first time that people have issues with node-port exposure because it works different than on `kubectl expose`.
No backport was requested. For now it's just documentation.
Hi Yan, thanks for the explanation. I just made the following commit, can you please review it? Thank you. https://github.com/openshift/openshift-docs/pull/12518/commits/bd4cff849c78c0db3f9e253f735a133ab03bac75
@Pan, PR LGTM, thanks!
Thanks Yan. Moving back to ON_QA
@yan can we mark it as verified?
@Nelly I'm ready to verify it after the code merged.
@pan, when can we expect to see this merged?
@Yan, @Nelly The PR in question is the entire documentation setup for CNV :) The PR will be merged when we publish the docs. Does that clarify things? Here is the docs preview as it currently stands: https://cnv_setup--ocpdocs.netlify.com/openshift-enterprise/latest/cnv_users_guide/cnv_users_guide.html#accessvmissh ...unless you meant you were waiting for Roman's PR to be merged?
no, thats good, we only had the PR from comment#18, so thought we need to wait for it, but if its in the guide, we can verify
The guide of access vmi by ssh looks good. Move to verified. Thanks @Pan