Connecting to a VM
Running the console Command
- To connect to the VM console, run the following command:
virtctl console testvm
- Enter the user credential specified during VM creation as prompted to access the VM console. If you no longer need the VM console, you can run the following command to exit the console:
Ctrl + ]
Using VNC
Huawei Cloud clusters allow you to use remote-viewer (installed on the client) to connect to VNC from the local host or enable the VNC proxy for remote connection.
- To start the local VNC viewer, run the following command:
virtctl vnc testvm
- To use the VNC proxy provided by a Huawei Cloud cluster for remote access, run the following command:
virtctl vnc --proxy-only testvm
Configuring an SSH Public Key
When managing VMs, a common operational pattern is to inject SSH public keys into VMs at startup time. In this way, you can use automation tools (such as Ansible) to configure VMs. It also gives operators a way of gaining secure, passwordless access to VMs. Huawei Cloud clusters provide multiple methods for injecting SSH public keys into VMs. Generally, these methods fall into two categories: static key injection and dynamic key injection.
- Static key injection places keys on VMs the first time they are started.
When creating a VM, you can use cloud-init to inject a startup script to the VM to allow multiple custom operations.
Method:
After an SSH public key is stored in a Kubernetes secret, the VM's access credential API allows statically injecting the SSH public key at VM startup time.
- After an SSH key pair is generated, the private key and public key (named id_rsa.pub) are generated in the directory where the related command is entered.
- The secret containing the public key is assigned to the VM through the access credential API with the noCloud propagation method.
- A Huawei Cloud cluster uses the generated cloud-init metadata instead of user data to inject an SSH public key into a VM.
- Create a Kubernetes secret to store the generated public key.
kubectl create secret generic my-pub-key --from-file=key1=id_rsa.pub
- Create a VM as follows:
kubectl create -f - <<EOF apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: testvm spec: runStrategy: Always template: spec: domain: devices: disks: - disk: bus: virtio name: containerdisk - disk: bus: virtio name: cloudinitdisk rng: {} resources: requests: memory: 1024M terminationGracePeriodSeconds: 0 accessCredentials: - sshPublicKey: source: secret: secretName: my-pub-key propagationMethod: noCloud: {} volumes: - containerDisk: image: quay.io/containerdisks/fedora:latest name: containerdisk - cloudInitNoCloud: userData: |- #cloud-config password: fedora chpasswd: { expire: False } name: cloudinitdisk EOF
- Wait for a while and run the following command to view the IP address of the VM:
kubectl get vmis
Example output:NAME AGE PHASE IP NODENAME READY testvm 12m Running 172.16.51.103 192.168.88.99 True
- Use the default username fedora of the Fedora image in the example to log in to the created VM in SSH mode without entering the password.
ssh fedora@172.16.51.103
- Dynamic key injection allows keys to be dynamically updated both at VM startup time and when the VM is running.
- New secrets cannot be attached to a VM when it is running. To attach a new secret, you must restart the VM.
- To use dynamic key injection, ensure that the qemu-guest-agent has been installed on the VM.
- When the qemuGuestAgent propagation method is used, the /home/$USER/.ssh/authorized_keys file will be owned by the guest agent. Changes to the file not made by the guest agent will be lost.
A Huawei Cloud cluster allows the dynamic injection of an SSH public key into a VM with the access credential API. The configured Kubernetes secret is attached to the VM through the qemuGuestAgent propagation method when the VM is started. This allows you to update the attached secret for the dynamic injection of an SSH public key when the VM is running.
- The dynamic key injection example is similar to the static key injection example, but the accessCredentials part is modified as follows:
accessCredentials: - sshPublicKey: source: secret: secretName: my-pub-key propagationMethod: qemuGuestAgent: users: - fedora
- In the cloudInitNoCloud part, SELinux needs to be disabled so that qemu-guest-agent can be modified.
authorized_keys:
- cloudInitNoCloud: userData: |- #cloud-config password: fedora chpasswd: { expire: False } # Disable SELinux for now, so qemu-guest-agent can write the authorized_keys file # The selinux-policy is too restrictive currently, see open bugs: # - https://bugzilla.redhat.com/show_bug.cgi?id=1917024 # - https://bugzilla.redhat.com/show_bug.cgi?id=2028762 # - https://bugzilla.redhat.com/show_bug.cgi?id=2057310 bootcmd: - setenforce 0
Feedback
Was this page helpful?
Provide feedbackThank you very much for your feedback. We will continue working to improve the documentation.See the reply and handling status in My Cloud VOC.
For any further questions, feel free to contact us through the chatbot.
Chatbot