Red Hat Training

A Red Hat training course is available for OpenShift Container Platform

Container-native Virtualization Release Notes

OpenShift Container Platform 3.11

Container-native Virtualization Release Notes

Red Hat OpenShift Documentation Team

Abstract

Known and fixed issues in this release of CNV

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.

Important

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 apiVersion has been updated from kubevirt.io/v1alpha2 to kubevirt.io/v1alpha3.
    • The volumeName attribute no longer exists. Ensure that each disk name matches the corresponding volume name in all configuration files.
    • All instances of registryDisk must be updated to containerDisk in configuration files.

1.3. Resolved issues

  • The runc package version runc-1.0.0-54 contained a bug that caused the virt-launcher to crash if FIPS was disabled. The version of runc containing 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-playbook command fails if the multus image 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-upload command fails if the --uploadproxy-url value 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)

    Note

    The 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 dataVolumeTemplates section 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 CrashLoopBackOff state, causing the PVC to enter a Terminating phase. 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-upload to upload a QCOW2 image to a PVC, the operation might fail with the error Unexpected 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 uploadserver pod 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 URL source 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)

    Note

    As a workaround, kill the relevant virt-handler pod 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 bridge mode, the virtual machine might stop if the kubelet gets restarted. (BZ#1685118)

Legal Notice

Copyright © 2020 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift, Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries.
Linux® is the registered trademark of Linus Torvalds in the United States and other countries.
Java® is a registered trademark of Oracle and/or its affiliates.
XFS® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States and/or other countries.
MySQL® is a registered trademark of MySQL AB in the United States, the European Union and other countries.
Node.js® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the official Joyent Node.js open source or commercial project.
The OpenStack® Word Mark and OpenStack logo are either registered trademarks/service marks or trademarks/service marks of the OpenStack Foundation, in the United States and other countries and are used with the OpenStack Foundation's permission. We are not affiliated with, endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.