List of available binding methods. Select the binding method suitable for the network interface:
-
Default pod network:
masquerade
-
Linux bridge network:
bridge
-
SR-IOV network:
SR-IOV
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 |
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.
Access to the website where you can download the URL link for the operating system image.
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.
You can quickly create a virtual machine (VM) by using a template with an available boot source.
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.
Click Events to view a stream of events as the VM is provisioned.
Click Console to verify that the VM booted successfully.
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).
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.
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.
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. |
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. |
The following advanced storage settings are optional and available for Blank, Import via URL, and Clone existing PVC disks. Before OKD Virtualization 4.11, if you do not specify these parameters, the system uses the default values from the kubevirt-storage-class-defaults
config map. In OKD Virtualization 4.11 and later, the system uses the default values from the storage profile.
Use storage profiles to ensure consistent advanced storage settings when provisioning storage for OKD Virtualization. To manually specify Volume Mode and Access Mode, you must clear the Apply optimized StorageProfile settings checkbox, which is selected by default. |
Name | Mode description | Parameter | Parameter description |
---|---|---|---|
Volume Mode |
Defines whether the persistent volume uses a formatted file system or raw block state. Default is Filesystem. |
Filesystem |
Stores the virtual disk on a file system-based volume. |
Block |
Stores the virtual disk directly on the block volume. Only use |
||
Access Mode |
Access mode of the persistent volume. |
ReadWriteOnce (RWO) |
Volume can be mounted as read-write by a single node. |
ReadWriteMany (RWX) |
Volume can be mounted as read-write by many nodes at one time.
|
||
ReadOnlyMany (ROX) |
Volume can be mounted as read only by many nodes. |
Name | Description |
---|---|
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.
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. |
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.
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.
You can create a virtual machine from a virtualMachine
manifest.
Edit the VirtualMachine
manifest for your VM. For example, the following manifest configures 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>
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. |
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. |
The VirtualMachineSpec
definition in the KubeVirt v0.59.0 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.