Volume Mode
Use one of these procedures to create a virtual machine:
Running the virtual machine wizard
Pasting a pre-configured YAML file with the virtual machine wizard
Using the CLI
Importing a VMware virtual machine or template with the virtual machine wizard
Do not create virtual machines in |
The web console features an interactive wizard that guides you through General, Networking, Storage, Advanced, and Review steps to simplify the process of creating virtual machines. All required fields are marked by a *
. When the required fields are completed, you can review and create your virtual machine.
Network interface controllers (NICs) and storage disks can be created and attached to virtual machines after they have been created.
If either URL
or Container
are selected as the Source in the General step, a rootdisk
disk is created and attached to the virtual machine as the Bootable Disk. You can modify the rootdisk
but you cannot remove it.
A Bootable Disk is not required for virtual machines provisioned from a PXE source if there are no disks attached to the virtual machine. If one or more disks are attached to the virtual machine, you must select one as the Bootable Disk.
When you create your virtual machine using the wizard, your virtual machine’s storage medium must support Read-Write-Many (RWX) PVCs.
Click Workloads → Virtualization from the side menu.
Click the Virtual Machines tab.
Click Create Virtual Machine and select New with Wizard.
Fill in all required fields in the General step. Selecting a Template automatically fills in these fields.
Click Next to progress to the Networking step. A nic0
NIC is attached by default.
Optional: Click Add Network Interface to create additional NICs.
Optional: You can remove any or all NICs by clicking the Options menu and selecting Delete. A virtual machine does not need a NIC attached to be created. NICs can be created after the virtual machine has been created.
Click Next to progress to the Storage screen.
Optional: Click Add Disk to create additional disks. These disks can be removed by clicking the Options menu and selecting Delete.
Optional: Click the Options menu to edit the disk and save your changes.
Click Review and Create. The Results screen displays the JSON configuration file for the virtual machine.
The virtual machine is listed in the Virtual Machines tab.
Refer to the virtual machine wizard fields section when running the web console wizard.
Name | Parameter | Description |
---|---|---|
Template |
Template from which to create the virtual machine. Selecting a template will automatically complete other fields. |
|
Source |
PXE |
Provision virtual machine from PXE menu. Requires a PXE-capable NIC in the cluster. |
URL |
Provision virtual machine from an image available from an HTTP or S3 endpoint. |
|
Container |
Provision virtual machine from a bootable operating system container located in a registry accessible from the cluster. Example: |
|
Disk |
Provision virtual machine from a disk. |
|
Operating System |
The primary operating system that is selected for the virtual machine. |
|
Flavor |
small, medium, large, tiny, Custom |
Presets that determine the amount of CPU and memory allocated to the virtual machine. The presets displayed for Flavor are determined by the operating system. |
Memory |
Size in GiB of the memory allocated to the virtual machine. |
|
CPUs |
The amount of CPU allocated to the virtual machine. |
|
Workload Profile |
High Performance |
A virtual machine configuration that is optimized for high-performance workloads. |
Server |
A profile optimized to run server workloads. |
|
Desktop |
A virtual machine configuration for use on a desktop. |
|
Name |
The name can contain lowercase letters ( |
|
Description |
Optional description field. |
|
Start virtual machine on creation |
Select to automatically start the virtual machine upon creation. |
Name | Description |
---|---|
Hostname |
Sets a specific hostname for the virtual machine. |
Authenticated 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. |
Source | Description |
---|---|
Container |
Specify the container path. For example: |
URL |
Specify the URL path and size in GiB. Then, select the storage class for this URL from the drop-down list. |
Attach Disk |
Select the virtual machine disk that you want to attach. |
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. For the default pod network, |
MAC Address |
MAC address for the network interface controller. If a MAC address is not specified, one is assigned automatically. |
Name | Description |
---|---|
Source |
Select a blank disk for the virtual machine or choose from the options available: URL, Container, Attach Cloned Disk, or Attach Disk. To select an existing disk and attach it to the virtual machine, choose Attach Cloned Disk or Attach Disk from a list of available persistent volume claims (PVCs). |
Name |
Name of the disk. The name can contain lowercase letters ( |
Size (GiB) |
Size, in GiB, of the disk. |
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 → Access Mode |
Access mode of the persistent volume. Supported access modes are ReadWriteOnce, ReadOnlyMany, and ReadWriteMany. |
The following advanced storage settings are available for Blank, Import via URL, and Clone existing PVC disks. These parameters are optional. If you do not specify these parameters, the system uses the default values from the kubevirt-storage-class-defaults
config map.
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 |
||
Access Mode |
Single User (RWO) |
The disk can be mounted as read/write by a single node. |
|
Shared Access (RWX) |
The disk can be mounted as read/write by many nodes.
|
||
Read Only (ROX) |
The disk can be mounted as read-only by many nodes. |
For more information on the kubevirt-storage-class-defaults
config map, see
Storage defaults for data volumes.
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 Workloads → Virtualization from the side menu.
Click the Virtual Machines tab.
Click Create Virtual Machine and select New from 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 in the Virtual Machines tab.
You can create a virtual machine from a virtualMachine
manifest.
Edit the VirtualMachine
manifest for your VM. For example, the following manifest configures a Red Hat Enterprise Linux (RHEL) 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 OpenShift Container Platform. 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 OpenShift 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/v1alpha3
kind: VirtualMachine
spec:
RunStrategy: Always (1)
template:
...
1 | The VMI’s current RunStrategy setting. |
The VirtualMachineSpec
definition in the KubeVirt v0.34.1 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 OpenShift Virtualization. |
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.