Product SiteDocumentation Site

3.2. Red Hat Virtualization Batch Update 1 (ovirt-4.1.2)

These release notes highlight Technology Preview items, recommended practices, known issues, and deprecated functionality to be taken into consideration when deploying this release of Red Hat Enterprise Virtualization.
Notes for updates released during the support lifecycle of this Red Hat Enterprise Virtualization release will appear in the advisory text associated with each update or the Red Hat Enterprise Virtualization Technical Notes. This document is available from the following page:

3.2.1. Enhancements

This release of Red Hat Enterprise Virtualization features the following enhancements:
BZ#1360983
With this update, the host name is automatically set to the virtual machine name in the RunOnce dialog. If required, this name can be changed.
BZ#1388433
Previously, the Manager's frequently updated PostgreSQL tables would fill up with obsolete data, creating the risk of disk flooding and transaction ID wraparound issues.

This release has introduced a more aggressive vacuum daemon configuration for collecting obsolete rows. This enables the Manager's tables to remain healthy, and for disk space usage to be better correlated with the actual amount of kept data.
BZ#1406398
Red Hat Virtualization Manager now supports NFS version 4.2 connections (when also supported by the storage).
BZ#1421533
In this release, the vdsm-client has been added as a dependency, and it replaces the now deprecated vdsClient.
BZ#1427790
Previously, it was possible to limit the highest SSL/TLS protocol version that was negotiated when establishing a connection between the Manager and VDSM. This was required for older clients.

In this release, this option has been removed from engine-config as it was verified that it is no longer required for VDSM 3.6 and later. VDSM 3.6 can successfully negotiate the highest available version.
BZ#1443508
Previously, ovirt-host-deploy failed if the collectd/fluentd packages and their plug-ins were not available.

In this release, if these packages are missing, ovirt-host-deploy emits a warning but does not fail. This enables a 3.6 host to be added to a 4.1 Manager, even though the 3.6 repositories do not include these packages.
BZ#1446056
Previously, after running engine-upgrade-check, the user was not informed that the system may not be up-to-date if engine-setup was not run after running yum update, for example. This is despite engine-upgrade-check stating that no upgrade is available. This has now been fixed so that a warning message is displayed to the user if engine-setup was not run.

3.2.2. Release Notes

This section outlines important details about the release, including recommended practices and notable changes to Red Hat Enterprise Virtualization. You must take this information into account to ensure the best possible outcomes for your deployment.
BZ#1367107
Previously, the API and Administration Portal differed in their firewall configuration when installing new hosts or reinstalling existing ones:

- Administration Portal – The firewall configuration was enabled by default.

- API – The firewall configuration was disabled by default and customers were required to specify the override_iptables=true parameter to complete the installation successfully. Alternatively, they had to manually configure the firewall prior to adding it to the Manager.

Now, both the API and the Administration Portal host installations enable firewall configuration by default.

Note that for customers upgrading to this release who are using API scripts to add hosts, if these scripts rely on the pre-4.1.2 API behavior to not configure the firewall, they must add override_iptables=false to their scripts.
BZ#1433961
Previously, it was possible to configure memory overcommit without setting memory ballooning or KSM control. This configuration affected the scheduling, but the memory was not freed. This has now been fixed by disabling ballooning and KSM by default, and setting memory optimization to “None” (100%).
BZ#1436161
The recommended number of logical volumes per storage domain was increased from 300 to 1000. The   alert that is issued when exceeding this number was changed to reflect that.

Note that the limit will only change to 1000 if it was set to 300. If the customer manually configured the limit, the original configuration will not be overridden.