7.12. Importing virtual machines
7.12.1. TLS certificates for DataVolume imports
7.12.1.1. Adding TLS certificates for authenticating DataVolume imports
TLS certificates for registry or HTTPS endpoints must be added to a ConfigMap in order to import data from these sources. This ConfigMap must be present in the namespace of the destination DataVolume.
Create the ConfigMap by referencing the relative file path for the TLS certificate.
Procedure
Ensure you are in the correct namespace. The ConfigMap can only be referenced by DataVolumes if it is in the same namespace.
$ oc get ns
Create the ConfigMap:
$ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>
7.12.1.2. Example: ConfigMap created from a TLS certificate
The following example is of a ConfigMap created from ca.pem
TLS certificate.
apiVersion: v1 kind: ConfigMap metadata: name: tls-certs data: ca.pem: | -----BEGIN CERTIFICATE----- ... <base64 encoded cert> ... -----END CERTIFICATE-----
7.12.2. Importing virtual machine images with DataVolumes
Use the Containerized Data Importer (CDI) to import a virtual machine image into a PersistentVolumeClaim (PVC) by using a DataVolume. You can attach a DataVolume to a virtual machine for persistent storage.
The virtual machine image can be hosted at an HTTP or HTTPS endpoint, or built into a container disk and stored in a container registry.
When you import a disk image into a PVC, the disk image is expanded to use the full storage capacity that is requested in the PVC. To use this space, the disk partitions and file system(s) in the virtual machine might need to be expanded.
The resizing procedure varies based on the operating system installed on the virtual machine. Refer to the operating system documentation for details.
7.12.2.1. Prerequisites
- If the endpoint requires a TLS certificate, the certificate must be included in a ConfigMap in the same namespace as the DataVolume and referenced in the DataVolume configuration.
To import a container disk:
- You might need to prepare a container disk from a virtual machine image and store it in your container registry before importing it.
-
If the container registry does not have TLS, you must add the registry to the
cdi-insecure-registries
ConfigMap before you can import a container disk from it.
- You might need to define a StorageClass or prepare CDI scratch space for this operation to complete successfully.
7.12.2.2. CDI supported operations matrix
This matrix shows the supported CDI operations for content types against endpoints, and which of these operations requires scratch space.
Content types | HTTP | HTTPS | HTTP basic auth | Registry | Upload |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ Supported operation
□ Unsupported operation
* Requires scratch space
** Requires scratch space if a custom certificate authority is required
7.12.2.3. About DataVolumes
DataVolume
objects are custom resources that are provided by the Containerized Data Importer (CDI) project. DataVolumes orchestrate import, clone, and upload operations that are associated with an underlying PersistentVolumeClaim (PVC). DataVolumes are integrated with KubeVirt, and they prevent a virtual machine from being started before the PVC has been prepared.
7.12.2.4. Importing a virtual machine image into a PersistentVolumeClaim by using a DataVolume
You can import a virtual machine image into a PersistentVolumeClaim (PVC) by using a DataVolume.
The virtual machine image can be hosted at an HTTP or HTTPS endpoint, or the image can be built into a container disk and stored in a container registry.
To create a virtual machine from an imported virtual machine image, specify the image or container disk endpoint in the VirtualMachine
configuration file before you create the virtual machine.
Prerequisites
-
You have installed the OpenShift CLI (
oc
). - Your cluster has at least one available PersistentVolume.
To import a virtual machine image you must have the following:
-
A virtual machine disk image in RAW, ISO, or QCOW2 format, optionally compressed by using
xz
orgz
. -
An HTTP endpoint where the image is hosted, along with any authentication credentials needed to access the data source. For example:
http://www.example.com/path/to/data
-
A virtual machine disk image in RAW, ISO, or QCOW2 format, optionally compressed by using
To import a container disk you must have the following:
-
A container disk built from a virtual machine image stored in your container image registry, along with any authentication credentials needed to access the data source. For example:
docker://registry.example.com/container-image
-
A container disk built from a virtual machine image stored in your container image registry, along with any authentication credentials needed to access the data source. For example:
Procedure
Optional: If your data source requires authentication credentials, edit the
endpoint-secret.yaml
file, and apply the updated configuration to the cluster:apiVersion: v1 kind: Secret metadata: name: <endpoint-secret> labels: app: containerized-data-importer type: Opaque data: accessKeyId: "" 1 secretKey: "" 2
$ oc apply -f endpoint-secret.yaml
Edit the virtual machine configuration file, specifying the data source for the virtual machine image you want to import. In this example, a Fedora image is imported from an
http
source:apiVersion: kubevirt.io/v1alpha3 kind: VirtualMachine metadata: creationTimestamp: null labels: kubevirt.io/vm: vm-fedora-datavolume name: vm-fedora-datavolume spec: dataVolumeTemplates: - metadata: creationTimestamp: null name: fedora-dv spec: pvc: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: local source: http: 1 url: "https://download.fedoraproject.org/pub/fedora/linux/releases/33/Cloud/x86_64/images/Fedora-Cloud-Base-33-1.2.x86_64.qcow2" 2 secretRef: "" 3 certConfigMap: "" 4 status: {} running: true template: metadata: creationTimestamp: null labels: kubevirt.io/vm: vm-fedora-datavolume spec: domain: devices: disks: - disk: bus: virtio name: datavolumedisk1 machine: type: "" 5 resources: requests: memory: 1.5Gi terminationGracePeriodSeconds: 60 volumes: - dataVolume: name: fedora-dv name: datavolumedisk1 status: {}
- 1
- The source type to import the image from. This example uses an HTTP endpoint. To import a container disk from a registry, replace
http
withregistry
. - 2
- The source of the virtual machine image you want to import. This example references a virtual machine image at an HTTP endpoint. An example of a container registry endpoint is
url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest"
. - 3
- The
secretRef
parameter is optional. - 4
- The
certConfigMap
is required for communicating with servers that use self-signed certificates or certificates not signed by the system CA bundle. The referenced ConfigMap must be in the same namespace as the DataVolume. - 5
- Specify
type: dataVolume
ortype: ""
. If you specify any other value fortype
, such aspersistentVolumeClaim
, a warning is displayed, and the virtual machine does not start.
Create the virtual machine:
$ oc create -f vm-<name>-datavolume.yaml
注意The
oc create
command creates the DataVolume and the virtual machine. The CDI controller creates an underlying PVC with the correct annotation, and the import process begins. When the import completes, the DataVolume status changes toSucceeded
, and the virtual machine is allowed to start.DataVolume provisioning happens in the background, so there is no need to monitor it. You can start the virtual machine, and it will not run until the import is complete.
Verification
The importer Pod downloads the virtual machine image or container disk from the specified URL and stores it on the provisioned PV. View the status of the importer Pod by running the following command:
$ oc get pods
Monitor the DataVolume status until it shows
Succeeded
by running the following command:$ oc describe dv <datavolume-name> 1
- 1
- The name of the DataVolume as specified under
dataVolumeTemplates.metadata.name
in the virtual machine configuration file. In the example configuration above, this isfedora-dv
.
To verify that provisioning is complete and that the VMI has started, try accessing its serial console by running the following command:
$ virtctl console <vm-fedora-datavolume>
7.12.3. Importing virtual machine images to block storage with DataVolumes
You can import an existing virtual machine image into your OpenShift Container Platform cluster. OpenShift Virtualization uses DataVolumes to automate the import of data and the creation of an underlying PersistentVolumeClaim (PVC).
When you import a disk image into a PVC, the disk image is expanded to use the full storage capacity that is requested in the PVC. To use this space, the disk partitions and file system(s) in the virtual machine might need to be expanded.
The resizing procedure varies based on the operating system that is installed on the virtual machine. Refer to the operating system documentation for details.
7.12.3.1. Prerequisites
- If you require scratch space according to the CDI supported operations matrix, you must first define a StorageClass or prepare CDI scratch space for this operation to complete successfully.
7.12.3.2. About DataVolumes
DataVolume
objects are custom resources that are provided by the Containerized Data Importer (CDI) project. DataVolumes orchestrate import, clone, and upload operations that are associated with an underlying PersistentVolumeClaim (PVC). DataVolumes are integrated with KubeVirt, and they prevent a virtual machine from being started before the PVC has been prepared.
7.12.3.3. About block PersistentVolumes
A block PersistentVolume (PV) is a PV that is backed by a raw block device. These volumes do not have a filesystem and can provide performance benefits for virtual machines by reducing overhead.
Raw block volumes are provisioned by specifying volumeMode: Block
in the PV and PersistentVolumeClaim (PVC) specification.
7.12.3.4. Creating a local block PersistentVolume
Create a local block PersistentVolume (PV) on a node by populating a file and mounting it as a loop device. You can then reference this loop device in a PV configuration as a Block
volume and use it as a block device for a virtual machine image.
Procedure
-
Log in as
root
to the node on which to create the local PV. This procedure usesnode01
for its examples. Create a file and populate it with null characters so that it can be used as a block device. The following example creates a file
loop10
with a size of 2Gb (20 100Mb blocks):$ dd if=/dev/zero of=<loop10> bs=100M count=20
Mount the
loop10
file as a loop device.$ losetup </dev/loop10>d3 <loop10> 1 2
Create a
PersistentVolume
configuration that references the mounted loop device.kind: PersistentVolume apiVersion: v1 metadata: name: <local-block-pv10> annotations: spec: local: path: </dev/loop10> 1 capacity: storage: <2Gi> volumeMode: Block 2 storageClassName: local 3 accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete nodeAffinity: required: nodeSelectorTerms: - matchExpressions: - key: kubernetes.io/hostname operator: In values: - <node01> 4
Create the block PV.
# oc create -f <local-block-pv10.yaml>1
- 1
- The filename of the PersistentVolume created in the previous step.
7.12.3.5. Importing a virtual machine image to a block PersistentVolume using DataVolumes
You can import an existing virtual machine image into your OpenShift Container Platform cluster. OpenShift Virtualization uses DataVolumes to automate the importing data and the creation of an underlying PersistentVolumeClaim (PVC). You can then reference the DataVolume in a virtual machine configuration.
Prerequisites
-
A virtual machine disk image, in RAW, ISO, or QCOW2 format, optionally compressed by using
xz
orgz
. -
An
HTTP
ors3
endpoint where the image is hosted, along with any authentication credentials needed to access the data source - At least one available block PV.
Procedure
If your data source requires authentication credentials, edit the
endpoint-secret.yaml
file, and apply the updated configuration to the cluster.Edit the
endpoint-secret.yaml
file with your preferred text editor:apiVersion: v1 kind: Secret metadata: name: <endpoint-secret> labels: app: containerized-data-importer type: Opaque data: accessKeyId: "" 1 secretKey: "" 2
Update the secret by running the following command:
$ oc apply -f endpoint-secret.yaml
Create a
DataVolume
configuration that specifies the data source for the image you want to import andvolumeMode: Block
so that an available block PV is used.apiVersion: cdi.kubevirt.io/v1alpha1 kind: DataVolume metadata: name: <import-pv-datavolume> 1 spec: storageClassName: local 2 source: http: url: <http://download.fedoraproject.org/pub/fedora/linux/releases/28/Cloud/x86_64/images/Fedora-Cloud-Base-28-1.1.x86_64.qcow2> 3 secretRef: <endpoint-secret> 4 pvc: volumeMode: Block 5 accessModes: - ReadWriteOnce resources: requests: storage: <2Gi>
Create the DataVolume to import the virtual machine image by running the following command:
$ oc create -f <import-pv-datavolume.yaml>1
- 1
- The file name of the DataVolume that you created in the previous step.
7.12.3.6. CDI supported operations matrix
This matrix shows the supported CDI operations for content types against endpoints, and which of these operations requires scratch space.
Content types | HTTP | HTTPS | HTTP basic auth | Registry | Upload |
---|---|---|---|---|---|
KubeVirt(QCOW2) |
✓ QCOW2 |
✓ QCOW2** |
✓ QCOW2 |
✓ QCOW2* |
✓ QCOW2* |
KubeVirt (RAW) |
✓ RAW |
✓ RAW |
✓ RAW |
✓ RAW* |
✓ RAW* |
✓ Supported operation
□ Unsupported operation
* Requires scratch space
** Requires scratch space if a custom certificate authority is required
7.12.4. Importing a single Red Hat Virtualization virtual machine
You can import a single Red Hat Virtualization (RHV) virtual machine into your OpenShift Container Platform cluster by using the virtual machine wizard or the CLI.
7.12.4.1. OpenShift Virtualization storage feature matrix
The following table describes local and shared persistent storage that support VM import.
RHV VM import | |
---|---|
OpenShift Container Storage: RBD block-mode volumes | Yes |
OpenShift Virtualization hostpath provisioner | No |
Other multi-node writable storage | Yes [1] |
Other single-node writable storage | Yes [2] |
- PVCs must request a ReadWriteMany access mode.
- PVCs must request a ReadWriteOnce access mode.
7.12.4.2. Prerequisites for importing a virtual machine
Importing a virtual machine into OpenShift Virtualization has the following prerequisites:
- You must have admin user privileges.
Storage:
- The OpenShift Virtualization local and shared persistent storage classes must support VM import.
- If you are using Ceph RBD block-mode volumes, the storage must be large enough to accommodate the virtual disk. If the disk is too large for the available storage, the import process fails and the PV that is used to copy the virtual disk is not released.
Networks:
- The source and target networks must either have the same name or be mapped to each other.
-
The source network interface must be
e1000
,rtl8139
, orvirtio
.
VM disks:
-
The disk interface must be
sata
,virtio_scsi
, orvirtio
. - The disk must not be configured as a direct LUN.
-
The disk status must not be
illegal
orlocked
. -
The storage type must be
image
. - SCSI reservation must be disabled.
-
ScsiGenericIO
must be disabled.
-
The disk interface must be
VM configuration:
- If the VM uses GPU resources, the nodes providing the GPUs must be configured.
- The VM must not be configured for vGPU resources.
-
The VM must not have snapshots with disks in an
illegal
state. - The VM must not have been created with OpenShift Container Platform and subsequently added to RHV.
- The VM must not be configured for USB devices.
-
The watchdog model must not be
diag288
.
7.12.4.3. Checking the default storage class
You must check the default storage class to ensure that it is NFS.
Cinder, the default storage class, does not support VM import.
7.12.4.3.1. Checking the default storage class in the OpenShift Container Platform console
You can check the default storage class in the OpenShift Container Platform console. If the default storage class is not NFS, you can change the default storage class so that it is no longer the default and change the NFS storage class so that it is the default.
If more than one default storage class is defined, the VirtualMachineImport CR uses the default storage class that is first in alphabetical order.
Procedure
-
Navigate to Storage
Storage Classes. - Check the default storage class in the Storage Classes list.
If the default storage class is not NFS, edit the default storage class so that it is no longer the default:
- Click the Options menu of the default storage class and select Edit Storage Class.
- In the Details tab, click the Edit button beside Annotations.
-
Click the Delete button
on the right side of the
storageclass.kubernetes.io/is-default-class
annotation and then click Save.
Change an existing NFS storage class to be the default:
- Click the Options menu of an existing NFS storage class and select Edit Storage Class.
- In the Details tab, click the Edit button beside Annotations.
-
Enter
storageclass.kubernetes.io/is-default-class
in the Key field andtrue
in the Value field and then click Save.
-
Navigate to Storage
Storage Classes to verify that the NFS storage class is the only default storage class.
7.12.4.3.2. Checking the default storage class from the CLI
You can check the default storage class from the CLI.
If the default storage class is not NFS, you must change the default storage class to NFS and change the existing default storage class so that it is not the default. If more than one default storage class is defined, the VirtualMachineImport CR uses the default storage class that is first in alphabetical order.
Procedure
Get the storage classes by entering the following command:
$ oc get sc
The default
storage class is displayed in the output:
Example output
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANS ... standard (default) kubernetes.io/cinder Delete WaitForFirstConsumer true
Changing the default storage class
If you are using AWS, use the following process to change the default storage class. This process assumes you have two storage classes defined, gp2
and standard
, and you want to change the default storage class from gp2
to standard
.
List the storage class:
$ oc get storageclass
Example output
NAME TYPE gp2 (default) kubernetes.io/aws-ebs 1 standard kubernetes.io/aws-ebs
- 1
(default)
denotes the default storage class.
Change the value of the annotation
storageclass.kubernetes.io/is-default-class
tofalse
for the default storage class:$ oc patch storageclass gp2 -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "false"}}}'
Make another storage class the default by adding or modifying the annotation as
storageclass.kubernetes.io/is-default-class=true
.$ oc patch storageclass standard -p '{"metadata": {"annotations": {"storageclass.kubernetes.io/is-default-class": "true"}}}'
Verify the changes:
$ oc get storageclass
Example output
NAME TYPE gp2 kubernetes.io/aws-ebs standard (default) kubernetes.io/aws-ebs
7.12.4.4. Creating a ConfigMap for importing a Red Hat Virtualization virtual machine
You can create a ConfigMap to map the Red Hat Virtualization (RHV) virtual machine operating system to an OpenShift Virtualization template if you want to override the default vm-import-controller
mapping or to add additional mappings.
The default vm-import-controller
ConfigMap contains the following RHV operating systems and their corresponding common OpenShift Virtualization templates.
RHV VM operating system | OpenShift Virtualization template |
---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Procedure
In a web browser, identify the REST API name of the RHV VM operating system by navigating to
http://<RHV_Manager_FQDN>/ovirt-engine/api/vms/<VM_ID>
. The operating system name appears in the<os>
section of the XML output, as shown in the following example:... <os> ... <type>rhel_8x64</type> </os>
View a list of the available OpenShift Virtualization templates:
$ oc get templates -n openshift --show-labels | tr ',' '\n' | grep os.template.kubevirt.io | sed -r 's#os.template.kubevirt.io/(.*)=.*#\1#g' | sort -u
Example output
fedora31 fedora32 ... rhel8.1 rhel8.2 ...
- If an OpenShift Virtualization template that matches the RHV VM operating system does not appear in the list of available templates, create a template with the OpenShift Virtualization web console.
Create a ConfigMap to map the RHV VM operating system to the OpenShift Virtualization template:
$ cat <<EOF | oc create -f - apiVersion: v1 kind: ConfigMap metadata: name: os-configmap namespace: default 1 data: guestos2common: | "Red Hat Enterprise Linux Server": "rhel" "CentOS Linux": "centos" "Fedora": "fedora" "Ubuntu": "ubuntu" "openSUSE": "opensuse" osinfo2common: | "<rhv-operating-system>": "<vm-template>" 2 EOF
ConfigMap example
$ cat <<EOF | oc apply -f - apiVersion: v1 kind: ConfigMap metadata: name: os-configmap namespace: default data: osinfo2common: | "other_linux": "fedora31" EOF
Verify that the custom ConfigMap was created:
$ oc get cm -n default os-configmap -o yaml
Edit the
kubevirt-hyperconverged-operator.v2.4.9.yaml
file:$ oc edit clusterserviceversion -n openshift-cnv kubevirt-hyperconverged-operator.v2.4.9
Update the following parameters of the
vm-import-operator
deployment manifest:... spec: containers: - env: ... - name: OS_CONFIGMAP_NAME value: os-configmap 1 - name: OS_CONFIGMAP_NAMESPACE value: default 2
Save the
kubevirt-hyperconverged-operator.v2.4.9.yaml
file.Updating the
vm-import-operator
deployment updates thevm-import-controller
ConfigMap.Verify that the template appears in the OpenShift Virtualization web console:
-
Click Workloads
Virtualization from the side menu. - Click the Virtual Machine Templates tab and find the template in the list.
-
Click Workloads
7.12.4.5. Importing a virtual machine with the VM Import wizard
You can import a single virtual machine with the VM Import wizard.
Procedure
-
In the web console, click Workloads
Virtual Machines. - Click Create Virtual Machine and select Import with Wizard.
- Select Red Hat Virtualization (RHV) from the Provider list.
Select Connect to New Instance or a saved RHV instance.
If you select Connect to New Instance, fill in the following fields:
-
API URL: For example,
https://<RHV_Manager_FQDN>/ovirt-engine/api
CA certificate: Click Browse to upload the RHV Manager CA certificate or paste the CA certificate into the field.
View the CA certificate by running the following command:
$ openssl s_client -connect <RHV_Manager_FQDN>:443 -showcerts < /dev/null
The CA certificate is the second certificate in the output.
-
Username: RHV Manager user name, for example,
admin@internal
- Password: RHV Manager password
-
API URL: For example,
- If you select a saved RHV instance, the wizard connects to the RHV instance using the saved credentials.
Click Check and Save and wait for the connection to complete.
注意The connection details are stored in a secret. If you add a provider with an incorrect URL, user name, or password, click Workloads
Secrets and delete the provider secret. - Select a cluster and a virtual machine.
- Click Next.
- In the Review screen, review your settings.
- Optional: You can select Start virtual machine on creation.
Click Edit to update the following settings:
-
General
Name: The VM name is limited to 63 characters. General
Description: Optional description of the VM. Storage Class: Select NFS or ocs-storagecluster-ceph-rbd.
If you select ocs-storagecluster-ceph-rbd, you must set the Volume Mode of the disk to Block.
-
Advanced
Volume Mode: Select Block.
-
Advanced
Volume Mode: Select Block. -
Networking
Network: You can select a network from a list of available network attachment definition objects.
-
General
Click Import or Review and Import, if you have edited the import settings.
A Successfully created virtual machine message and a list of resources created for the virtual machine are displayed. The virtual machine appears in Workloads
Virtual Machines.
Virtual machine wizard fields
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. |
Networking fields
Name | Description |
---|---|
Name | Name for the Network Interface Card. |
Model | Indicates the model of the Network Interface Card. Supported values are e1000, e1000e, ne2k_pci, pcnet, rtl8139, and virtIO. |
Network | List of available NetworkAttachmentDefinition objects. |
Type |
List of available binding methods. For the default Pod network, |
MAC Address | MAC address for the Network Interface Card. If a MAC address is not specified, an ephemeral address is generated for the session. |
Storage fields
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 PersistentVolumeClaims (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 |
Advanced |
Advanced storage settings
Name | Parameter | Description |
---|---|---|
Volume Mode | Filesystem | Stores the virtual disk on a filesystem-based volume. |
Block |
Stores the virtual disk directly on the block volume. Only use | |
Access Mode [1] | 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. |
- You can change the access mode by using the command line interface.
7.12.4.6. Importing a Red Hat Virtualization virtual machine with the CLI
You can import a Red Hat Virtualization (RHV) virtual machine with the CLI by creating the Secret and VirtualMachineImport Custom Resources (CRs). The Secret CR stores the RHV Manager credentials and CA certificate. The VirtualMachineImport CR defines the parameters of the VM import process.
Optional: You can create a ResourceMapping CR that is separate from the VirtualMachineImport CR. A ResourceMapping CR provides greater flexibility, for example, if you import additional RHV VMs.
The default target storage class must be NFS. Cinder does not support RHV VM import.
Procedure
Create the Secret CR by running the following command:
$ cat <<EOF | oc create -f - apiVersion: v1 kind: Secret metadata: name: rhv-credentials namespace: default 1 type: Opaque stringData: ovirt: | apiUrl: <api_endpoint> 2 username: admin@internal password: 3 caCert: | -----BEGIN CERTIFICATE----- 4 -----END CERTIFICATE----- EOF
- 1
- Optional. You can specify a different namespace in all the CRs.
- 2
- Specify the API endpoint of the RHV Manager, for example,
\"https://www.example.com:8443/ovirt-engine/api"
- 3
- Specify the password for
admin@internal
. - 4
- Specify the RHV Manager CA certificate. You can obtain the CA certificate by running the following command:
$ openssl s_client -connect :443 -showcerts < /dev/null
Optional: Create a
ResourceMapping
CR if you want to separate the resource mapping from theVirtualMachineImport
CR by running the following command:$ cat <<EOF | kubectl create -f - apiVersion: v2v.kubevirt.io/v1alpha1 kind: ResourceMapping metadata: name: resourcemapping_example namespace: default spec: ovirt: networkMappings: - source: name: <rhv_logical_network>/<vnic_profile> 1 target: name: <target_network> 2 type: pod storageMappings: 3 - source: name: <rhv_storage_domain> 4 target: name: <target_storage_class> 5 volumeMode: <volume_mode> 6 EOF
- 1
- Specify the RHV logical network and vNIC profile.
- 2
- Specify the OpenShift Virtualization network.
- 3
- If storage mappings are specified in both the
ResourceMapping
and theVirtualMachineImport
CRs, theVirtualMachineImport
CR takes precedence. - 4
- Specify the RHV storage domain.
- 5
- Specify
nfs
orocs-storagecluster-ceph-rbd
. - 6
- If you specified the
ocs-storagecluster-ceph-rbd
storage class, you must specifyBlock
as the volume mode.
Create the VirtualMachineImport CR by running the following command:
$ cat <<EOF | oc create -f - apiVersion: v2v.kubevirt.io/v1alpha1 kind: VirtualMachineImport metadata: name: vm-import namespace: default spec: providerCredentialsSecret: name: rhv-credentials namespace: default # resourceMapping: 1 # name: resourcemapping-example # namespace: default targetVmName: vm_example 2 startVm: true source: ovirt: vm: id: <source_vm_id> 3 name: <source_vm_name> 4 cluster: name: <source_cluster_name> 5 mappings: 6 networkMappings: - source: name: <source_logical_network>/<vnic_profile> 7 target: name: <target_network> 8 type: pod storageMappings: 9 - source: name: <source_storage_domain> 10 target: name: <target_storage_class> 11 accessMode: <volume_access_mode> 12 diskMappings: - source: id: <source_vm_disk_id> 13 target: name: <target_storage_class> 14 EOF
- 1
- If you create a ResourceMapping CR, uncomment the
resourceMapping
section. - 2
- Specify the target VM name.
- 3
- Specify the source VM ID, for example,
80554327-0569-496b-bdeb-fcbbf52b827b
. You can obtain the VM ID by enteringhttps://www.example.com/ovirt-engine/api/vms/
in a web browser on the Manager machine to list all VMs. Locate the VM you want to import and its corresponding VM ID. You do not need to specify a VM name or cluster name. - 4
- If you specify the source VM name, you must also specify the source cluster. Do not specify the source VM ID.
- 5
- If you specify the source cluster, you must also specify the source VM name. Do not specify the source VM ID.
- 6
- If you create a ResourceMapping CR, comment out the
mappings
section. - 7
- Specify the logical network and vNIC profile of the source VM.
- 8
- Specify the OpenShift Virtualization network.
- 9
- If storage mappings are specified in both the
ResourceMapping
and theVirtualMachineImport
CRs, theVirtualMachineImport
CR takes precedence. - 10
- Specify the source storage domain.
- 11
- Specify the target storage class.
- 12
- Specify
ReadWriteOnce
,ReadWriteMany
, orReadOnlyMany
. If no access mode is specified, {virt} determines the correct volume access mode based on the HostMigration mode setting of the RHV VM or on the virtual disk access mode: -
If the RHV VM migration mode is
Allow manual and automatic migration
, the default access mode isReadWriteMany
. -
If the RHV virtual disk access mode is
ReadOnly
, the default access mode isReadOnlyMany
. -
For all other settings, the default access mode is
ReadWriteOnce
.
-
If the RHV VM migration mode is
- Specify the source VM disk ID, for example,
8181ecc1-5db8-4193-9c92-3ddab3be7b05
. You can obtain the disk ID by enteringhttps://www.example.com/ovirt-engine/api/vms/vm23
in a web browser on the Manager machine and reviewing the VM details. - Specify the target storage class.
Follow the progress of the virtual machine import to verify that the import was successful:
$ oc get vmimports vm-import -n default
The output indicating a successful import resembles the following example:
Example output
... status: conditions: - lastHeartbeatTime: "2020-07-22T08:58:52Z" lastTransitionTime: "2020-07-22T08:58:52Z" message: Validation completed successfully reason: ValidationCompleted status: "True" type: Valid - lastHeartbeatTime: "2020-07-22T08:58:52Z" lastTransitionTime: "2020-07-22T08:58:52Z" message: 'VM specifies IO Threads: 1, VM has NUMA tune mode specified: interleave' reason: MappingRulesVerificationReportedWarnings status: "True" type: MappingRulesVerified - lastHeartbeatTime: "2020-07-22T08:58:56Z" lastTransitionTime: "2020-07-22T08:58:52Z" message: Copying virtual machine disks reason: CopyingDisks status: "True" type: Processing dataVolumes: - name: fedora32-b870c429-11e0-4630-b3df-21da551a48c0 targetVmName: fedora32
7.12.4.7. Canceling a virtual machine import
You can cancel a virtual machine import in progress by using the web console.
Procedure
-
Click Workloads
Virtual Machines. - Click the Options menu of the virtual machine you are importing and select Delete Virtual Machine.
In the Delete Virtual Machine window, click Delete.
The virtual machine is removed from the list of virtual machines.
7.12.4.8. Troubleshooting a virtual machine import
7.12.4.8.1. Logs
You can check the VM Import Controller Pod log for errors.
Procedure
View the VM Import Controller Pod name by running the following command:
$ oc get pods -n <namespace> | grep import 1
- 1
- Specify the namespace of your imported virtual machine.
Example output
vm-import-controller-f66f7d-zqkz7 1/1 Running 0 4h49m
View the VM Import Controller Pod log by running the following command:
$ oc logs <vm-import-controller-f66f7d-zqkz7> -f -n <namespace> 1
- 1
- Specify the VM Import Controller Pod name and the namespace.
7.12.4.8.2. Error messages
The following error message might appear:
The following error message is displayed in the VM Import Controller Pod log and the progress bar stops at 10% if the OpenShift Virtualization storage PV is not suitable:
Failed to bind volumes: provisioning failed for PVC
You must use a compatible storage class. The Cinder storage class is not supported.
7.12.5. Importing a single VMware virtual machine or template
You can import a VMware vSphere 6.5, 6.7, or 7.0 VM or VM template into OpenShift Virtualization by using the VM Import wizard.
If you import a VM template, OpenShift Virtualization creates a virtual machine based on the template.
7.12.5.1. OpenShift Virtualization storage feature matrix
The following table describes local and shared persistent storage that support VM import.
VMware VM import | |
---|---|
OpenShift Container Storage: RBD block-mode volumes | Yes |
OpenShift Virtualization hostpath provisioner | Yes |
Other multi-node writable storage | Yes [1] |
Other single-node writable storage | Yes [2] |
- PVCs must request a ReadWriteMany access mode.
- PVCs must request a ReadWriteOnce access mode.
7.12.5.2. Preparing a VDDK image
The import process uses the VMware Virtual Disk Development Kit (VDDK) to copy the VMware virtual disk.
You can download the VDDK SDK, create a VDDK image, upload the image to an image registry, and add it to the v2v-vmware
ConfigMap.
You can configure either an internal OpenShift Container Platform image registry or a secure external image registry for the VDDK image. The registry must be accessible to your OpenShift Virtualization environment.
Storing the VDDK image in a public registry might violate the terms of the VMware license.
7.12.5.2.1. Configuring an internal image registry
You can configure the internal OpenShift Container Platform image registry on bare metal by updating the Image Registry Operator configuration.
You can access the registry directly, from within the OpenShift Container Platform cluster, or externally, by exposing the registry with a route.
Changing the image registry’s management state
To start the image registry, you must change the Image Registry Operator configuration’s managementState
from Removed
to Managed
.
Procedure
Change
managementState
Image Registry Operator configuration fromRemoved
toManaged
. For example:$ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
Configuring registry storage for bare metal
As a cluster administrator, following installation you must configure your registry to use storage.
Prerequisites
- Cluster administrator permissions.
- A cluster on bare metal.
Persistent storage provisioned for your cluster, such as Red Hat OpenShift Container Storage.
重要OpenShift Container Platform supports
ReadWriteOnce
access for image registry storage when you have only one replica. To deploy an image registry that supports high availability with two or more replicas,ReadWriteMany
access is required.- Must have 100Gi capacity.
Procedure
To configure your registry to use storage, change the
spec.storage.pvc
in theconfigs.imageregistry/cluster
resource.注意When using shared storage, review your security settings to prevent outside access.
Verify that you do not have a registry pod:
$ oc get pod -n openshift-image-registry
注意If the storage type is
emptyDIR
, the replica number cannot be greater than1
.Check the registry configuration:
$ oc edit configs.imageregistry.operator.openshift.io
Example output
storage: pvc: claim:
Leave the
claim
field blank to allow the automatic creation of animage-registry-storage
PVC.Check the
clusteroperator
status:$ oc get clusteroperator image-registry
Accessing registry directly from the cluster
You can access the registry from inside the cluster.
Procedure
Access the registry from the cluster by using internal routes:
Access the node by getting the node’s address:
$ oc get nodes
$ oc debug nodes/<node_address>
To enable access to tools such as
oc
andpodman
on the node, run the following command:sh-4.2# chroot /host
Log in to the container image registry by using your access token:
sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443
sh-4.2# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000
You should see a message confirming login, such as:
Login Succeeded!
注意You can pass any value for the user name; the token contains all necessary information. Passing a user name that contains colons will result in a login failure.
Since the Image Registry Operator creates the route, it will likely be similar to
default-route-openshift-image-registry.<cluster_name>
.Perform
podman pull
andpodman push
operations against your registry:重要You can pull arbitrary images, but if you have the system:registry role added, you can only push images to the registry in your project.
In the following examples, use:
Component Value <registry_ip>
172.30.124.220
<port>
5000
<project>
openshift
<image>
image
<tag>
omitted (defaults to
latest
)Pull an arbitrary image:
$ podman pull name.io/image
Tag the new image with the form
<registry_ip>:<port>/<project>/<image>
. The project name must appear in this pull specification for OpenShift Container Platform to correctly place and later access the image in the registry:$ podman tag name.io/image image-registry.openshift-image-registry.svc:5000/openshift/image
注意You must have the
system:image-builder
role for the specified project, which allows the user to write or push an image. Otherwise, thepodman push
in the next step will fail. To test, you can create a new project to push the image.Push the newly tagged image to your registry:
$ podman push image-registry.openshift-image-registry.svc:5000/openshift/image
Exposing a secure registry manually
Instead of logging in to the OpenShift Container Platform registry from within the cluster, you can gain external access to it by exposing it with a route. This allows you to log in to the registry from outside the cluster using the route address, and to tag and push images using the route host.
Prerequisites:
The following prerequisites are automatically performed:
- Deploy the Registry Operator.
- Deploy the Ingress Operator.
Procedure
You can expose the route by using DefaultRoute
parameter in the configs.imageregistry.operator.openshift.io
resource or by using custom routes.
To expose the registry using DefaultRoute
:
Set
DefaultRoute
toTrue
:$ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
Log in with
podman
:$ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
$ podman login -u kubeadmin -p $(oc whoami -t) --tls-verify=false $HOST 1
- 1
--tls-verify=false
is needed if the cluster’s default certificate for routes is untrusted. You can set a custom, trusted certificate as the default certificate with the Ingress Operator.
To expose the registry using custom routes:
Create a secret with your route’s TLS keys:
$ oc create secret tls public-route-tls \ -n openshift-image-registry \ --cert=</path/to/tls.crt> \ --key=</path/to/tls.key>
This step is optional. If you do not create a secret, the route uses the default TLS configuration from the Ingress Operator.
On the Registry Operator:
spec: routes: - name: public-routes hostname: myregistry.mycorp.organization secretName: public-route-tls ...
注意Only set
secretName
if you are providing a custom TLS configuration for the registry’s route.
7.12.5.2.2. Configuring an external image registry
If you use an external image registry for the VDDK image, you can add the external image registry’s certificate authorities to the OpenShift Container Platform cluster.
Optionally, you can create a pull secret from your Docker credentials and add it to your service account.
Adding certificate authorities to the cluster
You can add certificate authorities (CA) to the cluster for use when pushing and pulling images with the following procedure.
Prerequisites
- You must have cluster administrator privileges.
-
You must have access to the public certificates of the registry, usually a
hostname/ca.crt
file located in the/etc/docker/certs.d/
directory.
Procedure
Create a
ConfigMap
in theopenshift-config
namespace containing the trusted certificates for the registries that use self-signed certificates. For each CA file, ensure the key in theConfigMap
is the hostname of the registry in thehostname[..port]
format:$ oc create configmap registry-cas -n openshift-config \ --from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \ --from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt
Update the cluster image configuration:
$ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge
Allowing pods to reference images from other secured registries
The .dockercfg
$HOME/.docker/config.json
file for Docker clients is a Docker credentials file that stores your authentication information if you have previously logged into a secured or insecure registry.
To pull a secured container image that is not from OpenShift Container Platform’s internal registry, you must create a pull secret from your Docker credentials and add it to your service account.
Procedure
If you already have a
.dockercfg
file for the secured registry, you can create a secret from that file by running:$ oc create secret generic <pull_secret_name> \ --from-file=.dockercfg=<path/to/.dockercfg> \ --type=kubernetes.io/dockercfg
Or if you have a
$HOME/.docker/config.json
file:$ oc create secret generic <pull_secret_name> \ --from-file=.dockerconfigjson=<path/to/.docker/config.json> \ --type=kubernetes.io/dockerconfigjson
If you do not already have a Docker credentials file for the secured registry, you can create a secret by running:
$ oc create secret docker-registry <pull_secret_name> \ --docker-server=<registry_server> \ --docker-username=<user_name> \ --docker-password=<password> \ --docker-email=<email>
To use a secret for pulling images for pods, you must add the secret to your service account. The name of the service account in this example should match the name of the service account the pod uses. The default service account is
default
:$ oc secrets link default <pull_secret_name> --for=pull
7.12.5.2.3. Creating and using a VDDK image
You can download the VMware Virtual Disk Development Kit (VDDK), build a VDDK image, and push the VDDK image to your image registry. You then add the VDDK image to the v2v-vmware
ConfigMap.
Prerequisites
- You must have access to an OpenShift Container Platform internal image registry or a secure external registry.
Procedure
Create and navigate to a temporary directory:
$ mkdir /tmp/<dir_name> && cd /tmp/<dir_name>
- In a browser, navigate to VMware code and click SDKs.
- Under Compute Virtualization, click Virtual Disk Development Kit (VDDK).
- Select the VDDK version that corresponds to your VMware vSphere version, for example, VDDK 7.0 for vSphere 7.0, click Download, and then save the VDDK archive in the temporary directory.
Extract the VDDK archive:
$ tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz
Create a
Dockerfile
:$ cat > Dockerfile <<EOF FROM busybox:latest COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib RUN mkdir -p /opt ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"] EOF
Build the image:
$ podman build . -t <registry_route_or_server_path>/vddk:<tag> 1
- 1
- Specify your image registry:
-
For an internal OpenShift Container Platform registry, use the internal registry route, for example,
image-registry.openshift-image-registry.svc:5000/openshift/vddk:<tag>
. -
For an external registry, specify the server name, path, and tag, for example,
server.example.com:5000/vddk:<tag>
.
-
For an internal OpenShift Container Platform registry, use the internal registry route, for example,
Push the image to the registry:
$ podman push <registry_route_or_server_path>/vddk:<tag>
- Ensure that the image is accessible to your OpenShift Virtualization environment.
Edit the
v2v-vmware
ConfigMap in the openshift-cnv project:$ oc edit configmap v2v-vmware -n openshift-cnv
Add the
vddk-init-image
parameter to thedata
stanza:... data: vddk-init-image: <registry_route_or_server_path>/vddk:<tag>
7.12.5.3. Importing a virtual machine with the VM Import wizard
You can import a single virtual machine with the VM Import wizard.
You can also import a VM template. If you import a VM template, OpenShift Virtualization creates a virtual machine based on the template.
Prerequisites
- You must have admin user privileges.
- The VMware Virtual Disk Development Kit (VDDK) image must be in an image registry that is accessible to your OpenShift Virtualization environment.
-
The VDDK image must be added to the
v2v-vmware
ConfigMap. - The VM must be powered off.
- Virtual disks must be connected to IDE or SCSI controllers. If virtual disks are connected to a SATA controller, you can change them to IDE controllers and then migrate the VM.
- The OpenShift Virtualization local and shared persistent storage classes must support VM import.
The OpenShift Virtualization storage must be large enough to accommodate the virtual disk.
警告If you try to import a virtual machine with a disk that is larger than the available storage space, the operation cannot complete. You will not be able to import another virtual machine or to clean up the storage because there are insufficient resources to support object deletion. To resolve this situation, you must add more object storage devices to the storage back end.
The OpenShift Virtualization egress network policy must allow the following traffic:
Destination Protocol Port VMware ESXi hosts
TCP
443
VMware ESXi hosts
TCP
902
VMware vCenter
TCP
5840
Procedure
-
In the web console, click Workloads
Virtual Machines. - Click Create Virtual Machine and select Import with Wizard.
- Select VMware from the Provider list.
Select Connect to New Instance or a saved vCenter instance.
- If you select Connect to New Instance, enter the vCenter hostname, Username, and Password.
- If you select a saved vCenter instance, the wizard connects to the vCenter instance using the saved credentials.
Click Check and Save and wait for the connection to complete.
注意The connection details are stored in a secret. If you add a provider with an incorrect host name, user name, or password, click Workloads
Secrets and delete the provider secret. - Select a virtual machine or a template.
- Click Next.
- In the Review screen, review your settings.
Click Edit to update the following settings:
General:
- Description
- Operating System
- Flavor
- Memory
- CPUs
- Workload Profile
Networking:
- Name
- Model
- Network
-
Type: You must select the
masquerade
binding method. - MAC Address
Storage: Click the Options menu of the VM disk and select Edit to update the following fields:
- Name
- Source: For example, Import Disk.
- Size
- Interface
Storage Class: Select NFS or ocs-storagecluster-ceph-rbd (ceph-rbd).
If you select ocs-storagecluster-ceph-rbd, you must set the Volume Mode of the disk to Block.
Other storage classes might work, but they are not officially supported.
-
Advanced
Volume Mode: Select Block. -
Advanced
Access Mode
Advanced
Cloud-init: - Form: Enter the Hostname and Authenticated SSH Keys.
-
Custom script: Enter the
cloud-init
script in the text field.
-
Advanced
Virtual Hardware: You can attach a virtual CD-ROM to the imported virtual machine.
Click Import or Review and Import, if you have edited the import settings.
A Successfully created virtual machine message and a list of resources created for the virtual machine are displayed. The virtual machine appears in Workloads
Virtual Machines.
Virtual machine wizard fields
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. |
Cloud-init fields
Name | Description |
---|---|
Hostname | Sets a specific host name 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. |
Networking fields
Name | Description |
---|---|
Name | Name for the Network Interface Card. |
Model | Indicates the model of the Network Interface Card. Supported values are e1000, e1000e, ne2k_pci, pcnet, rtl8139, and virtIO. |
Network | List of available NetworkAttachmentDefinition objects. |
Type |
List of available binding methods. For the default Pod network, |
MAC Address | MAC address for the Network Interface Card. If a MAC address is not specified, an ephemeral address is generated for the session. |
Storage fields
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 PersistentVolumeClaims (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 |
Advanced | |
Defines whether the persistent volume uses a formatted file system or raw block state. Default is Filesystem. |
Advanced |
Access mode of the persistent volume. Supported access modes are Single User (RWO), Shared Access (RWX), and Read Only (ROX). |
Advanced storage settings
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 filesystem-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. 注意 This is required for some features, such as live migration of virtual machines between nodes. | |
Read Only (ROX) | The disk can be mounted as read-only by many nodes. |
7.12.5.3.1. Updating the NIC name of an imported virtual machine
You must update the NIC name of a virtual machine that you imported from VMware to conform to OpenShift Virtualization naming conventions.
Procedure
- Log in to the virtual machine.
-
Navigate to the
/etc/sysconfig/network-scripts
directory. Rename the network configuration file:
$ mv vmnic0 ifcfg-eth0 1
- 1
- The first network configuration file is named
ifcfg-eth0
. Additional network configuration files are numbered sequentially, for example,ifcfg-eth1
,ifcfg-eth2
.
Update the
NAME
andDEVICE
parameters in the network configuration file:NAME=eth0 DEVICE=eth0
Restart the network:
$ systemctl restart network
7.12.5.4. Troubleshooting a virtual machine import
7.12.5.4.1. Logs
You can check the V2V Conversion Pod log for errors.
Procedure
View the V2V Conversion Pod name by running the following command:
$ oc get pods -n <namespace> | grep v2v 1
- 1
- Specify the namespace of your imported virtual machine.
Example output
kubevirt-v2v-conversion-f66f7d-zqkz7 1/1 Running 0 4h49m
View the V2V Conversion Pod log by running the following command:
$ oc logs <kubevirt-v2v-conversion-f66f7d-zqkz7> -f -n <namespace> 1
- 1
- Specify the VM Conversion Pod name and the namespace.
7.12.5.4.2. Error messages
The following error messages might appear:
If the VMware VM is not shut down before import, the imported virtual machine displays the error message,
Readiness probe failed
in the OpenShift Container Platform console and the V2V Conversion Pod log displays the following error message:INFO - have error: ('virt-v2v error: internal error: invalid argument: libvirt domain ‘v2v_migration_vm_1’ is running or paused. It must be shut down in order to perform virt-v2v conversion',)"
The following error message is displayed in the OpenShift Container Platform console if a non-admin user tries to import a VM:
Could not load ConfigMap vmware-to-kubevirt-os in kube-public namespace Restricted Access: configmaps "vmware-to-kubevirt-os" is forbidden: User cannot get resource "configmaps" in API group "" in the namespace "kube-public"
Only an admin user can import a VM.