3.7. Red Hat Virtualization Batch Update 6 (ovirt-4.1.7)
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.7.1. Enhancements
This release of Red Hat Enterprise Virtualization features the following enhancements:
- BZ#1490810
Previously, while VDSM performed periodic monitoring and maintenance tasks, operations would occasionally become too slow or even become blocked. In this case, the internal queue became full and the periodic operations were no longer performed. A "TooManyTasks" warning appeared in the log files at a maximum rate of once every 10 seconds. In this release, if VDSM cannot perform its periodic operations, in addition to issuing a warning in the log files, VDSM also dumps the contents of the queue into the logs.
- BZ#1502510
The precision of rx_rate, tx_rate, rx_drop, and tx_drop of virtual and host network interfaces have been increased. Network traffic 100 times smaller can now be detected on network interface statistics. If traffic on the network interface is below the precision of the network interface statistics, it is not reflected in the statistics.
- BZ#1502653
This release adds caching of the OVF storage location. As the OVF storage location rarely changes, it does not need to be searched for on every monitoring loop iteration. Instead it can be saved and reused, and expired only in the case of an error. As a result, the monitoring loop execution time is decreased significantly.
3.7.2. Known Issues
These known issues exist in Red Hat Enterprise Virtualization at this time:
- BZ#1399766
If no self-hosted engine host is available other than the host that is currently running the self-hosted engine, you will not be able to move the host that runs the Manager virtual machine to maintenance mode. Furthermore, even after another host moves to a status of "Up", it could take a few minutes for it to receive a score that will enable it to run the Manager virtual machine. The host will remain in a "preparing for maintenance" state until the Manager virtual machine can migrate to another host.
