Creating virtual machines
Use one of these procedures to create a virtual machine:
Quick Start guided tour
Quick create from the Catalog
Pasting a pre-configured YAML file with the virtual machine wizard
Using the CLI
Do not create virtual machines in |
When you create virtual machines from the web console, select a virtual machine template that is configured with a boot source. Virtual machine templates with a boot source are labeled as Available boot source or they display a customized label text. Using templates with an available boot source expedites the process of creating virtual machines.
Templates without a boot source are labeled as Boot source required. You can use these templates if you complete the steps for adding a boot source to the virtual machine.
Due to differences in storage behavior, some virtual machine templates are incompatible with single-node OpenShift. To ensure compatibility, do not set the |
Using a Quick Start to create a virtual machine
The web console provides Quick Starts with instructional guided tours for creating virtual machines. You can access the Quick Starts catalog by selecting the Help menu in the Administrator perspective to view the Quick Starts catalog. When you click on a Quick Start tile and begin the tour, the system guides you through the process.
Tasks in a Quick Start begin with selecting a Red Hat template. Then, you can add a boot source and import the operating system image. Finally, you can save the custom template and use it to create a virtual machine.
Prerequisites
- Access to the website where you can download the URL link for the operating system image.
Procedure
In the web console, select Quick Starts from the Help menu.
Click on a tile in the Quick Starts catalog. For example: Creating a Red Hat Linux Enterprise Linux virtual machine.
Follow the instructions in the guided tour and complete the tasks for importing an operating system image and creating a virtual machine. The Virtualization → VirtualMachines page displays the virtual machine.
Quick creating a virtual machine
You can quickly create a virtual machine (VM) by using a template with an available boot source.
Procedure
Click Virtualization → Catalog in the side menu.
Click Boot source available to filter templates with boot sources.
By default, the template list will show only Default Templates. Click All Items when filtering to see all available templates for your chosen filters.
Click a template to view its details.
Click Quick Create VirtualMachine to create a VM from the template.
The virtual machine Details page is displayed with the provisioning status.
Verification
Click Events to view a stream of events as the VM is provisioned.
Click Console to verify that the VM booted successfully.
Creating a virtual machine from a customized template
Some templates require additional parameters, for example, a PVC with a boot source. You can customize select parameters of a template to create a virtual machine (VM).
Procedure
In the web console, select a template:
Click Virtualization → Catalog in the side menu.
Optional: Filter the templates by project, keyword, operating system, or workload profile.
Click the template that you want to customize.
Click Customize VirtualMachine.
Specify parameters for your VM, including its Name and Disk source. You can optionally specify a data source to clone.
Verification
Click Events to view a stream of events as the VM is provisioned.
Click Console to verify that the VM booted successfully.
Refer to the virtual machine fields section when creating a VM from the web console.
Virtual machine fields
The following table lists the virtual machine fields that you can edit in the OKD web console:
Tab | Fields or functionality |
---|---|
Overview |
|
YAML |
|
Scheduling |
|
Environment |
|
Network Interfaces |
|
Disks |
|
Scripts |
|
Metadata |
|
Networking fields
Name | Description |
---|---|
Name | Name for the network interface controller. |
Model | Indicates the model of the network interface controller. Supported values are e1000e and virtio. |
Network | List of available network attachment definitions. |
Type | List of available binding methods. Select the binding method suitable for the network interface:
|
MAC Address | MAC address for the network interface controller. If a MAC address is not specified, one is assigned automatically. |
Storage fields
Name | Selection | Description | ||
---|---|---|---|---|
Source | Blank (creates PVC) | Create an empty disk. | ||
Import via URL (creates PVC) | Import content via URL (HTTP or HTTPS endpoint). | |||
Use an existing PVC | Use a PVC that is already available in the cluster. | |||
Clone existing PVC (creates PVC) | Select an existing PVC available in the cluster and clone it. | |||
Import via Registry (creates PVC) | Import content via container registry. | |||
Container (ephemeral) | Upload content from a container located in a registry accessible from the cluster. The container disk should be used only for read-only filesystems such as CD-ROMs or temporary virtual machines. | |||
Name | Name of the disk. The name can contain lowercase letters ( | |||
Size | Size of the disk in GiB. | |||
Type | Type of disk. Example: Disk or CD-ROM | |||
Interface | Type of disk device. Supported interfaces are virtIO, SATA, and SCSI. | |||
Storage Class | The storage class that is used to create the disk. | |||
Advanced → Volume Mode
| Defines whether the persistent volume uses a formatted file system or raw block state. Default is Filesystem. |
Advanced storage settings
Name | Parameter | Description | ||
---|---|---|---|---|
Volume Mode
| Filesystem | Stores the virtual disk on a file system-based volume. | ||
Block | Stores the virtual disk directly on the block volume. Only use |
Cloud-init fields
Name | Description |
---|---|
Hostname | Sets a specific hostname for the virtual machine. |
Authorized SSH Keys | The user’s public key that is copied to ~/.ssh/authorized_keys on the virtual machine. |
Custom script | Replaces other options with a field in which you paste a custom cloud-init script. |
To configure storage class defaults, use storage profiles. For more information, see Customizing the storage profile.
Pasting in a pre-configured YAML file to create a virtual machine
Create a virtual machine by writing or pasting a YAML configuration file. A valid example
virtual machine configuration is provided by default whenever you open the YAML edit screen.
If your YAML configuration is invalid when you click Create, an error message indicates the parameter in which the error occurs. Only one error is shown at a time.
Navigating away from the YAML screen while editing cancels any changes to the configuration you have made. |
Procedure
Click Virtualization → VirtualMachines from the side menu.
Click Create and select With YAML.
Write or paste your virtual machine configuration in the editable window.
- Alternatively, use the
example
virtual machine provided by default in the YAML screen.
- Alternatively, use the
Optional: Click Download to download the YAML configuration file in its present state.
Click Create to create the virtual machine.
The virtual machine is listed on the VirtualMachines page.
Using the CLI to create a virtual machine
You can create a virtual machine from a virtualMachine
manifest.
Procedure
Edit the
VirtualMachine
manifest for your VM. For example, the following manifest configures a Fedora VM:Example manifest for a Fedora VM
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
labels:
app: <vm_name> (1)
name: <vm_name>
spec:
dataVolumeTemplates:
- apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
name: <vm_name>
spec:
sourceRef:
kind: DataSource
name: rhel9
namespace: openshift-virtualization-os-images
storage:
resources:
requests:
storage: 30Gi
running: false
template:
metadata:
labels:
kubevirt.io/domain: <vm_name>
spec:
domain:
cpu:
cores: 1
sockets: 2
threads: 1
devices:
disks:
- disk:
bus: virtio
name: rootdisk
- disk:
bus: virtio
name: cloudinitdisk
interfaces:
- masquerade: {}
name: default
rng: {}
features:
smm:
enabled: true
firmware:
bootloader:
efi: {}
resources:
requests:
memory: 8Gi
evictionStrategy: LiveMigrate
networks:
- name: default
pod: {}
volumes:
- dataVolume:
name: <vm_name>
name: rootdisk
- cloudInitNoCloud:
userData: |-
#cloud-config
user: cloud-user
password: '<password>' (2)
chpasswd: { expire: False }
name: cloudinitdisk
1 Specify the name of the virtual machine. 2 Specify the password for cloud-user. Create a virtual machine by using the manifest file:
$ oc create -f <vm_manifest_file>.yaml
Optional: Start the virtual machine:
$ virtctl start <vm_name>
Virtual machine storage volume types
Storage volume type | Description | ||
---|---|---|---|
ephemeral | A local copy-on-write (COW) image that uses a network volume as a read-only backing store. The backing volume must be a PersistentVolumeClaim. The ephemeral image is created when the virtual machine starts and stores all writes locally. The ephemeral image is discarded when the virtual machine is stopped, restarted, or deleted. The backing volume (PVC) is not mutated in any way. | ||
persistentVolumeClaim | Attaches an available PV to a virtual machine. Attaching a PV allows for the virtual machine data to persist between sessions. Importing an existing virtual machine disk into a PVC by using CDI and attaching the PVC to a virtual machine instance is the recommended method for importing existing virtual machines into OKD. There are some requirements for the disk to be used within a PVC. | ||
dataVolume | Data volumes build on the Specify | ||
cloudInitNoCloud | Attaches a disk that contains the referenced cloud-init NoCloud data source, providing user data and metadata to the virtual machine. A cloud-init installation is required inside the virtual machine disk. | ||
containerDisk | References an image, such as a virtual machine disk, that is stored in the container image registry. The image is pulled from the registry and attached to the virtual machine as a disk when the virtual machine is launched. A Only RAW and QCOW2 formats are supported disk types for the container image registry. QCOW2 is recommended for reduced image size.
| ||
emptyDisk | Creates an additional sparse QCOW2 disk that is tied to the life-cycle of the virtual machine interface. The data survives guest-initiated reboots in the virtual machine but is discarded when the virtual machine stops or is restarted from the web console. The empty disk is used to store application dependencies and data that otherwise exceeds the limited temporary file system of an ephemeral disk. The disk capacity size must also be provided. |
About RunStrategies for virtual machines
A RunStrategy
for virtual machines determines a virtual machine instance’s (VMI) behavior, depending on a series of conditions. The spec.runStrategy
setting exists in the virtual machine configuration process as an alternative to the spec.running
setting. The spec.runStrategy
setting allows greater flexibility for how VMIs are created and managed, in contrast to the spec.running
setting with only true
or false
responses. However, the two settings are mutually exclusive. Only either spec.running
or spec.runStrategy
can be used. An error occurs if both are used.
There are four defined RunStrategies.
Always
A VMI is always present when a virtual machine is created. A new VMI is created if the original stops for any reason, which is the same behavior as spec.running: true
.
RerunOnFailure
A VMI is re-created if the previous instance fails due to an error. The instance is not re-created if the virtual machine stops successfully, such as when it shuts down.
Manual
The start
, stop
, and restart
virtctl client commands can be used to control the VMI’s state and existence.
Halted
No VMI is present when a virtual machine is created, which is the same behavior as spec.running: false
.
Different combinations of the start
, stop
and restart
virtctl commands affect which RunStrategy
is used.
The following table follows a VM’s transition from different states. The first column shows the VM’s initial RunStrategy
. Each additional column shows a virtctl command and the new RunStrategy
after that command is run.
Initial RunStrategy | start | stop | restart |
---|---|---|---|
Always | - | Halted | Always |
RerunOnFailure | - | Halted | RerunOnFailure |
Manual | Manual | Manual | Manual |
Halted | Always | - | - |
In OKD Virtualization clusters installed using installer-provisioned infrastructure, when a node fails the MachineHealthCheck and becomes unavailable to the cluster, VMs with a RunStrategy of |
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
RunStrategy: Always (1)
template:
...
1 | The VMI’s current RunStrategy setting. |
Additional resources
The
VirtualMachineSpec
definition in the KubeVirt v0.53.2 API Reference provides broader context for the parameters and hierarchy of the virtual machine specification.The KubeVirt API Reference is the upstream project reference and might contain parameters that are not supported in OKD Virtualization.
Enable the CPU Manager to use the high-performance workload profile.
See Prepare a container disk before adding it to a virtual machine as a
containerDisk
volume.See Deploying machine health checks for further details on deploying and enabling machine health checks.
See Installer-provisioned infrastructure overview for further details on installer-provisioned infrastructure.
See Configuring the SR-IOV Network Operator for further details on the SR-IOV Network Operator.