Skip to content

Commit 72738fb

Browse files
apinnickapinnick
authored
Merge pull request #61419 from apinnick/CNV-29929-connecting-to-vms
CNV -29929: Improve 'Connecting to VM consoles' and 'Connecting with SSH'
2 parents 61f0f95 + 5710ed3 commit 72738fb

27 files changed

+859
-320
lines changed

‎_topic_maps/_topic_map.yml

Lines changed: 4 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -3629,6 +3629,10 @@ Topics:
36293629
###VIRTUAL MACHINE CHESS SALAD (silly name to highlight that the commented out assemblies need to be checked against merged filenams)
36303630
- Name: Creating virtual machines
36313631
File: virt-create-vms
3632+
- Name: Connecting to VM consoles
3633+
File: virt-accessing-vm-consoles
3634+
- Name: Configuring SSH access to VMs
3635+
File: virt-accessing-vm-ssh
36323636
- Name: Editing virtual machines
36333637
File: virt-edit-vms
36343638
- Name: Editing boot order
@@ -3641,8 +3645,6 @@ Topics:
36413645
File: virt-manage-vmis
36423646
- Name: Controlling virtual machine states
36433647
File: virt-controlling-vm-states
3644-
- Name: Accessing virtual machine consoles
3645-
File: virt-accessing-vm-consoles
36463648
- Name: Automating Windows installation with sysprep
36473649
File: virt-automating-windows-sysprep
36483650
- Name: Installing the QEMU guest agent and VirtIO drivers

‎modules/virt-about-services.adoc

Lines changed: 4 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -1,18 +1,17 @@
11
// Module included in the following assemblies:
22
//
33
// * virt/virtual_machines/vm_networking/virt-creating-service-vm.adoc
4+
// * virt/virtual_machines/virt-accessing-vm-ssh.adoc
45

56
:_content-type: CONCEPT
67
[id="virt-about-services_{context}"]
78
= About services
89

9-
A Kubernetes _service_ exposes network access for clients to an application running on a set of pods. Services offer abstraction, load balancing, and, in the case of NodePort and LoadBalancer, exposure to the outside world.
10+
A Kubernetes service exposes network access for clients to an application running on a set of pods. Services offer abstraction, load balancing, and, in the case of the `NodePort` and `LoadBalancer` types, exposure to the outside world.
1011

11-
Services can be exposed in the *VirtualMachine details* -> *Details* tab of the web console or by specifying a `spec.type` in the `Service` object:
12+
ClusterIP:: Exposes the service on an internal IP address and as a DNS name to other applications within the cluster. A single service can map to multiple virtual machines. When a client tries to connect to the service, the client's request is load balanced among available backends. `ClusterIP` is the default service type.
1213

13-
ClusterIP:: Exposes the service on an internal IP address and as a DNS name to other applications within the cluster. A single service can map to multiple virtual machines. When a client tries to connect to the service, the client's request is load balanced among available backends. `ClusterIP` is the default service `type`.
14-
15-
NodePort:: Exposes the service on the same port of each selected node in the cluster. `NodePort` makes a service accessible from outside the cluster.
14+
NodePort:: Exposes the service on the same port of each selected node in the cluster. `NodePort` makes a port accessible from outside the cluster, as long as the node itself is externally accessible to the client.
1615

1716
LoadBalancer:: Creates an external load balancer in the current cloud (if supported) and assigns a fixed, external IP address to the service.
1817

‎modules/virt-access-configuration-considerations.adoc

Lines changed: 41 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,41 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/virtual_machines/virt-accessing-vm-ssh.adoc
4+
5+
:_content-type: REFERENCE
6+
[id="virt-access-configuration-considerations_{context}"]
7+
= Access configuration considerations
8+
9+
Each method for configuring access to a virtual machine (VM) has advantages and limitations, depending on the traffic load and client requirements.
10+
11+
Services provide excellent performance and are recommended for applications that are accessed from outside the cluster.
12+
13+
If the internal cluster network cannot handle the traffic load, you can configure a secondary network.
14+
15+
`virtctl ssh` and `virtctl port-forwarding` commands::
16+
* Simple to configure.
17+
* Recommended for troubleshooting VMs.
18+
* `virtctl port-forwarding` recommended for automated configuration of VMs with Ansible.
19+
* Not recommended for high-traffic applications like Rsync or Remote Desktop Protocol because of the burden on the API server.
20+
* The API server must be able to handle the traffic load.
21+
* The clients must be able to access the API server.
22+
* The clients must have access credentials for the cluster.
23+
24+
Cluster IP service::
25+
* The internal cluster network must be able to handle the traffic load.
26+
* The clients must be able to access an internal cluster IP address.
27+
28+
Node port service::
29+
* The internal cluster network must be able to handle the traffic load.
30+
* The clients must be able to access at least one node.
31+
32+
Load balancer service::
33+
* A load balancer must be configured.
34+
* Each node must be able to handle the traffic load of one or more load balancer services.
35+
36+
Secondary network::
37+
* Excellent performance because traffic does not go through the internal cluster network.
38+
* Allows a flexible approach to network topology.
39+
* Guest operating system must be configured with appropriate security because the VM is exposed directly to the secondary network. If a VM is compromised, an intruder could gain access to the secondary network.
40+
41+

‎modules/virt-accessing-vmi-ssh.adoc

Lines changed: 0 additions & 89 deletions
This file was deleted.

‎modules/virt-adding-static-public-key-cli.adoc

Lines changed: 151 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,151 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/virtual_machines/virt-accessing-vm-ssh.adoc
4+
5+
:_content-type: PROCEDURE
6+
[id="virt-adding-static-public-key-cli_{context}"]
7+
= Adding an SSH key when creating a virtual machine by using the command line
8+
9+
You can add a _static_ public SSH key when you create a virtual machine (VM) by using the command line. The key is added to the VM at startup.
10+
11+
The SSH key is added to the VM as generated cloud-init metadata, by using a cloud-init configuration disk. This method separates the access credentials from the application data in the cloud-init user data. This method does not affect cloud-init user data.
12+
13+
.Prerequisites
14+
15+
* You generated an SSH key pair by running the `ssh-keygen` command.
16+
17+
.Procedure
18+
19+
. Create a manifest file for a `VirtualMachine` object and a `Secret` object:
20+
+
21+
[source,yaml]
22+
----
23+
apiVersion: kubevirt.io/v1
24+
kind: VirtualMachine
25+
metadata:
26+
name: example-vm
27+
namespace: example-namespace
28+
spec:
29+
dataVolumeTemplates:
30+
- apiVersion: cdi.kubevirt.io/v1beta1
31+
kind: DataVolume
32+
metadata:
33+
name: example-vm-disk
34+
spec:
35+
sourceRef:
36+
kind: DataSource
37+
name: rhel9
38+
namespace: openshift-virtualization-os-images
39+
storage:
40+
resources:
41+
requests:
42+
storage: 30Gi
43+
running: false
44+
template:
45+
metadata:
46+
labels:
47+
kubevirt.io/domain: example-vm
48+
spec:
49+
domain:
50+
cpu:
51+
cores: 1
52+
sockets: 2
53+
threads: 1
54+
devices:
55+
disks:
56+
- disk:
57+
bus: virtio
58+
name: rootdisk
59+
- disk:
60+
bus: virtio
61+
name: cloudinitdisk
62+
interfaces:
63+
- masquerade: {}
64+
name: default
65+
rng: {}
66+
features:
67+
smm:
68+
enabled: true
69+
firmware:
70+
bootloader:
71+
efi: {}
72+
resources:
73+
requests:
74+
memory: 8Gi
75+
evictionStrategy: LiveMigrate
76+
networks:
77+
- name: default
78+
pod: {}
79+
volumes:
80+
- dataVolume:
81+
name: example-volume
82+
name: example-vm-disk
83+
- cloudInitConfigDrive: <1>
84+
userData: |-
85+
#cloud-config
86+
user: cloud-user
87+
password: <password>
88+
chpasswd: { expire: False }
89+
name: cloudinitdisk
90+
accessCredentials:
91+
- sshPublicKey:
92+
propagationMethod:
93+
configDrive: {}
94+
source:
95+
secret:
96+
secretName: authorized-keys <2>
97+
---
98+
apiVersion: v1
99+
kind: Secret
100+
metadata:
101+
name: authorized-keys
102+
data:
103+
key: |
104+
MIIEpQIBAAKCAQEAulqb/Y... <3>
105+
----
106+
<1> Specify `cloudInitConfigDrive` to create a configuration drive.
107+
<2> Specify the `Secret` object name.
108+
<3> Paste the public SSH key.
109+
110+
. Create the `VirtualMachine` and `Secret` objects:
111+
+
112+
[source,terminal]
113+
----
114+
$ oc create -f <manifest_file>.yaml
115+
----
116+
117+
. Start the VM:
118+
+
119+
[source,terminal]
120+
----
121+
$ virtctl start vm example-vm
122+
----
123+
124+
.Verification
125+
. Get the VM configuration:
126+
+
127+
[source,terminal]
128+
----
129+
$ oc describe vm example-vm -n example-namespace
130+
----
131+
+
132+
.Example output
133+
[source,yaml]
134+
----
135+
apiVersion: kubevirt.io/v1
136+
kind: VirtualMachine
137+
metadata:
138+
name: example-vm
139+
namespace: example-namespace
140+
spec:
141+
template:
142+
spec:
143+
accessCredentials:
144+
- sshPublicKey:
145+
propagationMethod:
146+
configDrive: {}
147+
source:
148+
secret:
149+
secretName: authorized-keys
150+
----
151+

‎modules/virt-adding-static-public-key-project-web.adoc

Lines changed: 37 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,37 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/virtual_machines/virt-accessing-vm-ssh.adoc
4+
5+
:_content-type: PROCEDURE
6+
[id="adding-static-public-key-project-web_{context}"]
7+
= Adding an SSH key to a project by using the web console
8+
9+
You can add a _static_ public SSH key to a project by using the {product-title} web console. Afterwards, this key is added to the virtual machines (VMs) that you create in the project.
10+
11+
A static public key is added to a VM at startup as cloud-init metadata. This method does not affect cloud-init user data.
12+
13+
.Prerequisites
14+
15+
* You generated an SSH key pair by running the `ssh-keygen` command.
16+
17+
.Procedure
18+
19+
. Navigate to *Virtualization* -> *Overview* in the web console.
20+
. On the *Settings* tab, click the *User* tab.
21+
. Expand *Manage SSH keys*.
22+
. Select a project from the *Project* list and click the edit icon.
23+
. Select an SSH key option:
24+
25+
* *Use existing*: Select a secret from the secrets list.
26+
* *Add new*:
27+
.. Browse to the public SSH key file or paste the file in the key field.
28+
.. Enter the secret name.
29+
30+
. Click *Save*.
31+
32+
.Verification
33+
. Create a VM in the same project as the SSH key.
34+
. Click the VM to view the *VirtualMachine details* page.
35+
. Click the *Scripts* tab on the *Configuration* tab.
36+
+
37+
The secret name is displayed in the *Authorized SSH key* section.

0 commit comments

Comments
 (0)