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

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.

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.

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.

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.

Red Hat Virtualization Manager now supports NFS version 4.2 connections (when also supported by the storage).

Red Hat Virtualization Manager now supports NFS version 4.2 connections (when also supported by the storage).

In this release, the vdsm-client has been added as a dependency, and it replaces the now deprecated vdsClient.

In this release, the vdsm-client has been added as a dependency, and it replaces the now deprecated vdsClient.

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.

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.

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.

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.

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.

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.

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.

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.

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%).

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%).

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.

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.