## Virtuozzo Infrastructure System 8.0 (8.0.0-390) ### Overview This update provides security and stability fixes. ### Fixed issues - [VSTOR-150696] A security fix for CVE-2026-99999. - [VSTOR-94442] A Kubernetes cluster update could fail with "Stack UPDATE cancelled" when duplicate resize requests were submitted. Additional resize requests are now rejected while a resize or upgrade is in progress. - [VSTOR-137444] Kubernetes cluster configuration requests could fail with a gateway timeout during an update, because a single unbounded Keystone call could make the whole Magnum API unresponsive on a node. - [VSTOR-140018] New self-service projects were allowed to create VM migrations by default; their migration quota now defaults to 0 until an administrator enables it. - [VSTOR-143824] Device mapper operations, such as mounting, snapshotting, or resizing ploop devices, could fail on a host running many such operations concurrently because a system setting reduced the System V semaphore limits below the kernel defaults. - [VSTOR-148210] libvirtd could crash during a VM migration if it had previously been restarted while VMs were running. - [VSTOR-148486] The "Cluster has only one MDS" alert now says it can be ignored on a deliberate single-node installation. - [VSTOR-148890] The hardware compatibility check for version 8.0 reported TPM 2.0 modules as incompatible, although their drivers are built into the 8.0 kernel. - [VSTOR-149326] Admin panel requests could take 30 seconds or longer when a connection to the identity service stalled. Requests now retry promptly and return a clear error if the service remains unavailable. - [VSTOR-149963] After an upgrade from version 7.4, the migration quota for the admin project had to be manually set to unlimited. - [VSTOR-150110] A check for updates could fail with "Process was interrupted" while it installed dependencies, because the daily automatic package update ran at the same time and released a lock the check relied on. - [VSTOR-150356] Exclusive traffic types, such as VM backups, could not be changed during guided setup on a single node. - [VSTOR-150464] A storage policy for external storage could not be created in the admin panel on a cluster with only local storage tiers. - [VSTOR-150470] Uploaded images did not appear on a cluster deployed with local storage on one node and later extended for high availability of the management node. - [VSTOR-150522] After an upgrade to version 8.0, a node could start without network connectivity because the new initramfs lacked the NIC drivers and bonds started without their member interfaces. - [VSTOR-150611] The Cyber Frame connector is updated to version 1.47.0+1010. - [VSTOR-150632] Storage garbage collection could add up to 30% extra I/O load on virtual machines with erasure-coded volumes. ------------------------------------------------------ ## Virtuozzo Infrastructure System 8.0 (formerly Virtuozzo Infrastructure) ### Overview This major release introduces the V/IS Lite deployment model, general availability of the VMware migration service, and a guided initial setup wizard. It also delivers storage performance improvements, enhanced security controls, and updated kernel, driver, Kubernetes, and guest operating system support. Starting with this release, the product name changes from Virtuozzo Infrastructure to Virtuozzo Infrastructure System (V/IS). ### What's new #### V/IS Lite deployment - V/IS Lite deployment. Introduced the V/IS Lite deployment model: a V/IS cluster with local storage. Each Lite deployment has its own admin panel, self-service panel, and alerting capabilities. #### Migration - VMware migration service. The migration service is now generally available for administrators and self-service users. It supports project-level access control, CPU and RAM hotplug, and migration of VMs with multiple volumes. #### Onboarding - Guided initial setup. Introduced a setup wizard that enables administrators to configure compute and storage services through a single guided workflow during the first login. ### Improvements #### Performance and efficiency - Compute performance profiles. Added support for selecting a performance profile for the compute cluster, which defines how much CPU and RAM the compute services reserve on each node. - Storage space allocation. Improved data distribution across chunk servers with different capacities. #### Object storage - Metadata sharding. Improved object storage performance through metadata sharding, reducing GET and PUT request latency by approximately 10%. - Parallel geo-replication. Improved geo-replication performance through parallel processing, increasing write performance by up to 80%. #### Security - API access permissions. Added support for controlling API access through user permissions. Administrators can specify which users can access the API and require API credentials for authentication. #### Compute and virtualization - Windows Subsystem for Linux 2 (WSL2) support. Added support for running WSL2 in Windows Server 2022, Windows Server 2025, Windows 10, and Windows 11 virtual machines. #### Administration - Two-factor authentication notifications. Added an option to hide the two-factor authentication (2FA) banner in the admin panel. ### Kernel and driver updates - Linux kernel. Updated to version 6.12. - NVIDIA drivers. Updated to the NVIDIA R595 driver branch. - NVIDIA vGPU software. Updated to version 20. - Huawei storage driver. Added the official Huawei driver version 25.3.0. Storages attached with the legacy driver must be switched to the official driver manually. - Hitachi Cinder driver. Updated to version 2.5.0. ### Kubernetes support - Kubernetes. Updated to version 1.36.2. - Fedora CoreOS. Updated the base operating system image for managed Kubernetes clusters to Fedora CoreOS 44. ### Guest OS support Added support for the following guest operating systems: - Ubuntu 26.04 LTS - SUSE Linux Enterprise Server (SLES) 16 The following guest operating systems are deprecated: - CentOS 6 ### Important notes - Hardware compatibility. Version 8.0 introduces a new operating system and kernel stack based on RHEL 10. Before upgrading, verify that your cluster hardware meets the compatibility requirements for version 8.0. Use the hardware compatibility checker available on GitHub to identify unsupported hardware. - NVIDIA driver requirements. Before upgrading to version 8.0, ensure that nodes with NVIDIA GPUs or vGPUs have NVIDIA vGPU software driver version 595.58.03 or later installed. ### Fixed issues - [VSTOR-89672] Entering and exiting node maintenance mode could leave an entire network without DHCP if a VM created during maintenance took the IP address released by the DHCP port. - [VSTOR-100175] Bringing a physical interface down and back up could reset the MTU of all OVS VLANs on that interface to the MTU of the physical interface. - [VSTOR-111339] An IP address shared as an allowed address pair by multiple ports could be unreachable from other internal networks connected to the same router. - [VSTOR-114776] DHCP could stop working for all subnets of a network when one subnet ran out of available IP addresses. - [VSTOR-121149] Distributed virtual routers could fail to initialize after adding a new controller node to the compute cluster, leaving VMs without external connectivity. - [VSTOR-123307] VMs using multiqueue virtio-net, such as Windows or BSD guests, could lose inbound network connectivity after live migration or a save-and-restore operation. - [VSTOR-124254] Invalidating cached data for a very large file could block the storage client for several seconds, potentially triggering a node reboot. - [VSTOR-124460] Repeatedly resetting the HA state of a router in quick succession could leave all router instances in standby, making floating IPs and services behind load balancers unreachable. - [VSTOR-127604] A stability fix for the storage client mount, which could crash while reading data in clusters where chunk servers had been removed. - [VSTOR-128349] Updating the primary management node could fail, leaving the management backend IP address active on two HA nodes. - [VSTOR-129677] Applying changes to load balancers with many listeners, pools, and members, such as Kubernetes-managed load balancers, could take a long time and cause amphora heartbeat loss. - [VSTOR-133475] False-positive alerts could be triggered under a high rate of HTTP requests because metric collection timed out. - [VSTOR-133911] VM live migration could fail if the VM's domain still contained a network interface associated with a deleted port. - [VSTOR-135394] VPN connections could remain stuck in the PENDING_CREATE state and could not be resynchronized when a VPN peer or local ID was set to a subnet value. - [VSTOR-136450] The memory reserved for the host system on a node could periodically drop to zero. - [VSTOR-136849] The Neutron OVS agent could stall for several minutes after a compute node reboot, and port checks could trigger false-positive alerts when a global MAC prefix was configured. - [VSTOR-136981] Chunk services could fail while synchronizing storage during a cluster update. - [VSTOR-137278] Adding a file storage node could fail with "empty role is not allowed" if the node had no roles assigned. - [VSTOR-137539] A load balancer could remain stuck in the PENDING_UPDATE state after an amphora failover. - [VSTOR-137664] A brief control-plane outage could trigger mass failover of healthy amphorae, leaving load balancers in the ERROR state until manual recovery. - [VSTOR-137754] VM tags could be missing from backup export data and therefore not restored when a backup was restored to a new VM. - [VSTOR-138814] After a keepalived split-brain condition, the gateway and SNAT ports of an HA router could remain bound to a standby node, triggering false host binding alerts. - [VSTOR-139584] Retrieving information about or forcing failover of a load balancer with many pools could time out in the admin panel or CLI. - [VSTOR-140570] A false-positive "Software RAID is degraded" alert could be triggered for Intel IMSM metadata container devices. - [VSTOR-141175] Creating a VM from an image with consolidation inheritance enabled but no consolidation tags could fail. - [VSTOR-142365] The "Edit storage policy" wizard could silently change the redundancy scheme when changing the tier, triggering unexpected data re-encoding. - [VSTOR-145864] The "License" page displayed only the CPU cores of compute nodes instead of the total cluster core count used for usage reporting and billing. - [VSTOR-146975] Garbage collection could stall on files with continuous I/O, preventing freed space from being reclaimed and causing volume usage to continue growing. - [VSTOR-147040] Garbage collection could stall during large-scale re-encoding, causing excessive storage overhead until re-encoding completed. ### Known issues - V/IS Lite deployment. Virtual machines cannot be migrated between separate Lite clusters. - Migration service. Migration of CentOS 6 guest operating systems is not supported. - [VSTOR-118852] The object storage service can crash when processing S3 requests larger than 132 KB. By default, the S3 gateway sends requests of up to 256 KB. - [VSTOR-126474] Putting a controller node into maintenance mode interrupts SNAT and floating IP traffic of the routers on that node until they move to another node. The downtime grows with the number of routers: moving 100 routers can take more than one minute. - [VSTOR-129392] A VM with a floating IP can lose external connectivity for up to tens of seconds during live migration, especially under heavy memory load. - [VSTOR-133743] During a node reboot, public ports with multiple VLANs can be blocked by switch loop protection because external OVS bridges start flooding traffic between VLANs. - [VSTOR-135413] Entering and exiting maintenance mode does not wait for HA routers to migrate or initialize, so rolling updates of controller nodes can cause routing outages on clusters with hundreds of virtual routers. - [VSTOR-138558] An S3 name server can repeatedly restart when its commit journal grows to tens of gigabytes, because replaying the journal on startup takes longer than the service startup timeout. This causes an S3 outage that requires manual intervention. This can occur, for example, after deleting a bucket with a very large number of objects. - [VSTOR-139921] Creating or updating a network interface becomes slower as the number of VLANs on a node increases, from about 8 seconds on a node with one interface to about 70 seconds with 150 VLAN interfaces. - [VSTOR-140044] During a rolling update of clusters with thousands of ports per node, an updated node can fail to connect new or migrated VMs to the network for tens of minutes, potentially leaving load balancers in the ERROR state. - [VSTOR-140073] A VM disk image left in an inconsistent state can be reopened for writing without repair, potentially causing silent guest data corruption.