Virtuozzo Infrastructure 7.4 Hotfix 4 (7.4.0-108)¶
Issue date: 2026-10-13
Applies to: Virtuozzo Infrastructure 7.4
Virtuozzo Advisory ID: VZA-2026-026
1. Overview¶
This update provides stability fixes, including improvements to the upgrade process to version 8.0.
2. Bug Fixes¶
An upgrade to version 8.0 could rename network interfaces on nodes with bonds because Leapp matched interfaces by their current, non-unique MAC addresses instead of their permanent ones. (VSTOR-75762)
Sequential write performance over RDMA could degrade because completion interrupts from all RDMA connections were handled by a single CPU. (VSTOR-124948)
A node could be rebooted by the HA service during a software update because HA monitoring resumed while the old storage mount was still renewing its heartbeat, including when retrying a failed update. (VSTOR-125693, VSTOR-146983)
The admin panel could fail to load with an HTTP 500 error after an update if its nginx location configuration files had been manually modified and were not replaced. (VSTOR-128647)
VM availability metrics could remain at zero until the libvirt exporter was restarted. (VSTOR-130930, VSTOR-148243)
Retrieving storage parameters for a backup gateway deployment could fail with an internal server error if the storage type had no parameters. (VSTOR-134533, VSTOR-145711)
Creating a compute cluster could fail if a Mellanox NIC link remained down for a minute or longer while an OVS bridge was being configured. (VSTOR-136599)
A stability fix for the object storage configuration service. (VSTOR-136911)
Identity provider mapping rules had a size limit that was insufficient for deployments with many customers. (VSTOR-137755)
The MTU of a VLAN created on an OVS bridge with MTU 1500 was not saved to the interface configuration and could be lost after a reboot. (VSTOR-141184)
RDMA transfers could stall for 20 to 40 seconds when an RDMA memory limit was configured, significantly reducing aggregate storage throughput. (VSTOR-141673, VSTOR-145048)
The hardware compatibility check could incorrectly report chipset PCI Express root ports and CPU controllers as incompatible. (VSTOR-142088)
A kernel stability fix for the storage client. (VSTOR-143521)
A VM with a QXL display could crash due to heap corruption when the SPICE display updated the mouse cursor. (VSTOR-144000)
The hardware compatibility check for version 8.0 could incorrectly report ConnectX-3 and ConnectX-3 Pro NICs as unsupported, although they remain available as unmaintained devices. (VSTOR-145951, VSTOR-147656)
A QEMU live update during a software update could crash VMs with NUMA-bound memory, causing a hard reset of the guest. (VSTOR-147016)
Live migration of a VM with backup change-tracking bitmaps could crash QEMU on both nodes, causing VM failure, for example, during evacuation for an update. (VSTOR-147066)
After an update to version 7.4, Windows VMs could recognize their network adapters as new devices and lose static IP settings because a USB controller change shifted PCI addresses. (VSTOR-147219, VSTOR-147852)
An update to version 8.0 could fail while the management node was still installing the new kernel because the per-node kernel update timeout was too short. (VSTOR-147520)
VMs live-migrated during an update could lose network connectivity for tens of seconds because migration started before the destination node finished configuring network ports. (VSTOR-147540, VSTOR-147811)
Traffic from remote security group members could be dropped after a port belonging to the same security group left the host. (VSTOR-148106)
An update to version 8.0 could fail on nodes with the default 1 GiB /boot partition because the “Not enough space on / or /boot” check failed after downloading the update. (VSTOR-148339)
Added an eligibility check that blocks an upgrade to version 8.0 if the runtime network settings of a node differ from those saved in its interface configuration files. (VSTOR-148396)
An upgrade to version 8.0 could rename network interfaces because Leapp did not create the files required to preserve interface names. (VSTOR-148910)
Windows guests could lose their DNS server settings on networks with more than 12 DHCP-enabled IPv4 subnets. DHCP option 249 is no longer sent by default, which raises the limit to 26 subnets without host routes. (VSTOR-149167)