Virtual Machine (VM) Wizard helps to manage VMs on Kubernetes. Users can deploy VM workload on their Kubernetes cluster using VM Wizard, deploy Virtual Machine in a Kubernetes container and establish communication with other pods.
VM wizard is a packaging format to deploy Virtual Machines using KubeVirt. KubeVirt contains a lot of components required to deploy in the cluster. KubeVirt uses CRDs, controllers and other Kubernetes features, to represent and manage traditional virtual machines alongside containers. Using KubeVirt, users can standardize the settings on Kubernetes, and easily handle applications and virtual machines or manage two entirely separate stacks.
KubeVirt delivers three (3) things to provide the new functionality:
- Additional types, Custom Resource Definition (CRD) added to the Kubernetes API
- Additional controllers for cluster wide logic associated with the new types
- Additional daemons for node specific logic associated with new types
To deploy VMs on Kubernetes, create a custom blueprint and select the checkbox VM Operator from the Managed System Add-Ons drop-down. This action deploys KubeVirt components in the cluster to enable virtualization (or Kubevirt) in the New Version of blueprint. Refer Custom Blueprint.
- Login into the Console (typically as a Project Admin)
- Navigate to Applications -> Workloads
- Click on New Workload and provide a name for the Workload
- Select VM Wizard from Package Type drop-down and a Namespace from Namespace drop-down where the resources should be deployed
- Click Continue
Ensure that a namespace where you would like to deploy has already been created.
Configuration details are customer defined. Provide the General, Storage, and Advanced configuration details for the new workload.
- Specify the CPU and Memory for the workload
- Select Start VM on Creation (optional) checkbox to start the VM on successful creation of Workload
The Storage is to configure volumes for the Workloads.
- Enter the storage name and size of the storage
- Select the image type from the Source Image Type drop-down
- For URL image type, two volumes are mandatory, where one is bootable and other non-bootable. Click Add Volume to provide the non-bootable volume name and size. Use delete icon to remove the additional volumes
Specify the bootable volume size a little higher than the size of the image provided.
- For ContainerDisk source, one bootable volume is mandatory
In the Advanced options, users can attach the existing Service Accounts, Secrets, and ConfigMaps as disk to the VM. Users can add multiple entries for each option.
- Service Account: A service account to access the cluster running on different operating systems with a secured authentication
- Secrets: Secrets are K8s resources, containing a small amount of sensitive data such as a password, token, or key
- ConfigMaps: ConfigMap, an API object used to store non-confidential data in key-value pairs
Advanced settings are optional.
Placement in the controller to indicate the "intent" for where/how the user wish to operate their applications. Depending on the nature of the application, they may have very different ways of tracking the Service Level Objective (SLO).
Select a Drift Action
NotSet: Allow anyone to perform actions on the target clusters without restrictions
- DetectAndNotify: Allow the authorised users to perform actions on the target clusters, detect the actions and notify through alerts
BlockAndNotify: Restrict the users to perform any actions on the target clusters for security purpose. Blocked notifications are sent through alerts.
Select a Placement Policy type
- Specific Locations: Allows to select the clusters within a specific region or location
- Specific Clusters: Allows to select a specific cluster
- Custom Labels: Allows to select the clusters available with specific labels
In the example below, NotSet and Specific Clusters are selected.
- Click SAVE & GO TO PUBLISH to save and publish the workload
Click SAVE & RETURN TO CONFIGURATION to save the placement data and return to configuration section if any modifications required (or) DISCARD CHANGES & EXIT to abort the process.
For more information, refer placement policy
Workload is now ready to publish. Click Publish to start the deployment process.
Click RETURN TO PLACEMENT to return to the placement and perform the required modifications (or) DISCARD CHANGES & EXIT to abort the process and exit the configuration page.
Depending on the complexity of the placement policy (e.g. multiple clusters, different location clusters), the workload deployment process can take 30 seconds to a few minutes, showing the status.
An appropriate status appears on successful deployment. The below image shows the status Ready.
Click Unpublish to remove the deployed VMs on the remote clusters (or) Republish to deploy the VM again if any changes performed recently.
If the remote cluster is offline when initiating the unpublish operation, the Controller send this instruction to the cluster when it reconnects.
Use the Card View or Table View icons to view the workload details like status, namespace, last modified date & time, etc on the main workload list page. Card view is default
To get the list of workloads in the table view, use the Table View icon. Clicking on Deployment Status Ready workload shows the current state of the workload by cluster
If there are any issues during deployment, both the application developer and/or the operations user will require RBAC secure facilities to remotely debug.
- Navigate to the workload's publish screen (or) click Options from the main workload list page
- Click Debug to view the deployed VM name, Namespace, Age (time in minutes since the deployment is complete), status, and actions
- Actions allows the users to start, pause, stop and refresh the deployed VMs whenever required
For more information on Debug, refer Debug