이 콘텐츠는 선택한 언어로 제공되지 않습니다.
Chapter 1. Container-native Virtualization Release Notes
1.1. Product overview
1.1.1. Introduction to Container-native Virtualization
Container-native Virtualization is an add-on to OpenShift Container Platform that allows virtual machine workloads to run and be managed alongside container workloads. You can create virtual machines from disk images imported using the containerized data importer (CDI) controller, or from scratch within OpenShift Container Platform.
Container-native Virtualization introduces two new objects to OpenShift Container Platform:
- Virtual Machine: The virtual machine in OpenShift Container Platform
- Virtual Machine Instance: A running instance of the virtual machine
With the Container-native Virtualization add-on, virtual machines run in pods and have the same network and storage capabilities as standard pods.
Existing virtual machine disks are imported into persistent volumes (PVs), which are made accessible to Container-native Virtualization virtual machines using persistent volume claims (PVCs). In OpenShift Container Platform, the virtual machine object can be modified or replaced as needed, without affecting the persistent data stored on the PV.
Container-native Virtualization is currently a Technology Preview feature. For details about Red Hat support for Container-native Virtualization, see the Container-native Virtualization - Technology Preview Support Policy.
Technology Preview features are not supported with Red Hat production service level agreements (SLAs), might not be functionally complete, and Red Hat does not recommend to use them for production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.
For more information on Red Hat Technology Preview features support scope, see https://access.redhat.com/support/offerings/techpreview/.
1.2. New and changed features
1.2.1. Introducing Operators
- Operators power the installation of KubeVirt, Containerized Data Importer, and the web-ui in Container-native Virtualization 1.4.
1.2.2. Updated KubeVirt API
A new version of the KubeVirt API is included in Container-native Virtualization 1.4. Several important changes are reflected in the latest configuration file templates.
-
The
apiVersionhas been updated fromkubevirt.io/v1alpha2tokubevirt.io/v1alpha3. -
The
volumeNameattribute no longer exists. Ensure that each disk name matches the corresponding volume name in all configuration files. -
All instances of
registryDiskmust be updated tocontainerDiskin configuration files.
-
The
1.3. Resolved issues
-
The
runcpackage versionrunc-1.0.0-54contained a bug that caused the virt-launcher to crash if FIPS was disabled. The version ofrunccontaining the fix is now shipped with Red Hat Enterprise Linux 7 Extras. (BZ1650512) - In the Create Virtual Machine Wizard, using the PXE source option with the Start virtual machine on creation option resulted in the boot order not changing after stopping and starting the virtual machine. This issue has been resolved. (BZ#1648245) (BZ#1647447)
1.4. Known issues
- CPU Manager, a feature that provides CPU pinning in OpenShift Container Platform, is currently disabled in Container-native Virtualization due to performance regressions. CPU Manager does not consider the physical CPU topology, resulting in sub-optimal pinning when hyper-threading is enabled. (BZ#1667854)
- Red Hat OpenShift Container Storage versions before 3.11.1 are not compatible with Container-native Virtualization. In the incompatible versions, Gluster nodes do not deploy with CRI-O as the container runtime. (BZ#1651270)
-
When installing Container-native Virtualization 1.4, the
ansible-playbookcommand fails if themultusimage and its underlying layers are not pulled within the timeout period. As a workaround, wait a few minutes and try the command again. (BZ#1664274) -
The
virtctl image-uploadcommand fails if the--uploadproxy-urlvalue ends with a trailing slash. If you use a custom URL, ensure that it does not end with a trailing slash before running the command. (BZ#1660888) - The limit for compute node devices is currently 110. This limit cannot be configured, but scaling up to more than 110 devices will be supported in a future release. (BZ#1673438)
When uploading or importing a disk image to a PVC, the space allocated for the PVC must be at least
2 * actual image size + virtual image size. Otherwise, the virtual machine does not boot successfully. (BZ#1676824)NoteThe command
$ ls -sh <image_file>reports the actual size. For uncompressed raw images, the command$ ls -lh <image_file>reports the virtual size. For QCOW2 images, use$ qemu-img info <image_file>to get both values.-
If you create a new DataVolume while a PVC already exists with the same name, the DataVolume enters an unrecoverable error state. If this DataVolume is associated with a virtual machine, or if it was created with the
dataVolumeTemplatessection of a virtual machine configuration file, then the virtual machine will fail to start. In these cases, the underlying DataVolume error will not be propagated to the virtual machine. (BZ#1669163) -
If a CDI import into a PVC fails, a request to delete the PVC might not work immediately. Instead, the importer pod gets stuck in a
CrashLoopBackOffstate, causing the PVC to enter aTerminatingphase. To resolve this issue, find the importer pod associated with the PVC and delete it. The PVC will then be deleted. (BZ#1673683) If you use
virtctl image-uploadto upload a QCOW2 image to a PVC, the operation might fail with the errorUnexpected return value 500, resulting in an unusable PVC. This can be caused by a bug where conversion of certain QCOW2 images during an upload operation exceeds predefined process limits. (BZ#1679134)To confirm that the failure was caused by this bug, check the associated
uploadserverpod logs for a message like this:1 uploadserver.go:203] Saving stream failed: data stream copy failed: Local qcow to raw conversion failed: could not convert local qcow2 image to raw: qemu-img execution failed: signal: killed
As a workaround, locally convert the file to compressed raw format and then upload the result:
$ qemu-img convert -f qcow2 -O raw <failing-image.qcow2> image.raw $ gzip image.raw $ virtctl image-upload ... image.raw.gz
-
When a virtual machine provisioned from a
URLsource is started for the first time, the virtual machine will be in the Importing state while Container-native Virtualization imports the container from the endpoint URL.
Restarting a virtual machine while it is in the Importing state results in an error. (BZ#1673921) If the kubelet on a node crashes or restarts, this causes the kubelet to incorrectly report 0 KVM devices. Virtual machines are not properly scheduled on affected nodes.
Verify the number of devices that the kubelet reports by running:
$ oc get node $NODE | grep devices.kubevirt
The output on an affected node shows
devices.kubevirt.io/kvm: 0. (BZ#1681175)NoteAs a workaround, kill the relevant
virt-handlerpod on the affected node. The pod automatically restarts, and the kubelet reports the correct number of available KVM devices.-
If a virtual machine is connected to the pod network by using
bridgemode, the virtual machine might stop if the kubelet gets restarted. (BZ#1685118)
