Skip to main content

What's new in vStack Center 3.2.0

User-visible changes by release, newest first.

3.2.0 — September 25, 2026​

This release adds no new API methods. All changes are fixes, and almost all address the same issue: Center no longer decides how to handle a virtual machine solely from a record in its database. Before starting a machine, it now asks the nodes where the machine is actually running. After a failure, it distinguishes a machine crash from a normal guest shutdown and recovers the machine, and stopping a pool service finally accounts for machines running on neighboring nodes.

Highlights​

  • A machine can no longer be started on a second node while it is running on the first. Before starting it, Center queries the nodes and rejects the start with code -461 if the machine is already running somewhere. Previously, when the database differed from reality, the command was still sent to the second node — and two hypervisors wrote to the same disk.
  • A machine that crashes is recovered. Center no longer treats a hypervisor crash as an administrator shutdown and starts the machine as soon as its storage is ready — including if it crashed after the pool had already started.
  • Stopping a pool service also shuts down remotely running machines. Previously, Center shut down only machines on the owner node; the others kept the pool busy, and export failed with "pool is busy".
  • The virtual machine list no longer repeats the same machine.

Upgrade considerations​

  • The response to a machine start arrives later — by the time taken to query the nodes. The default query budget is 10 seconds for all nodes combined (not per node), configured by the VM_LIVENESS_PROBE_TIMEOUT_SECS environment variable. Querying can be disabled entirely (VM_LIVENESS_PROBE_ENABLED=0) — in that case, starting, automatic recovery, and the "machine is not running" branch of stopping work as they did before 3.2.0.
  • A new error code -461 is available: "VM is running on another cluster node; unable to start". API clients that handle start failures by code must account for it. The node number is intentionally omitted from the message — it is recorded in the service log.
  • Automatic recovery after a failure depends on the node agent. The vStack OS 3.2.0 agent reports the reason for a machine shutdown. On nodes with an older agent, a machine shut down abnormally is still considered to have been stopped by the administrator and is not recovered automatically — update the agent on all nodes.
  • Stopping a pool service now shuts down that pool's machines on neighboring nodes. When planning maintenance, account for shutdowns of machines beyond those on the owner node.

Fixed​

Starting and stopping a machine

  • A virtual machine can no longer be started on a second node while it is running on the first. If the nodes do not respond, the start is not blocked: an unavailable node must not prevent machines from starting after a failure — that is the very scenario recovery is intended for. Automatic recovery of machines follows the same rule.
  • Stopping a machine no longer marks it as stopped if it is running on another node. A node's "no such machine is running" response is true for that node but not for the cluster — Center accepted it as fact and recorded the machine as stopped, after which starting it on another node passed validation. The state is now recorded only after checking with the nodes. The response to the stop operation itself has not changed — it still completes successfully.
  • Two concurrent requests to start the same machine on different nodes no longer both proceed: one runs, and the second receives the existing "machine is already running" error.
  • Starting a machine immediately after its migration between pools completes is no longer rejected with "machine is locked". Previously, marking the migration as complete and unlocking the machine were separate operations: the machine was already shown as migrated, but the lock was released a couple of seconds later — and a start requested during that interval was rejected. The lock is now released at the same time as migration is marked complete, so the migrated machine can be started immediately.

Automatic recovery after a failure

  • A machine crash no longer clears its "should be running" flag. Previously, a hypervisor crash and a normal guest shutdown reached Center as the same event, and either marked the machine as stopped by the administrator — so automatic recovery no longer started it after a failure. Center now distinguishes the reason using data from the node and preserves the flag after a crash, a guest-requested restart, a node shutdown, or a forced shutdown due to a timeout. A normal guest shutdown still moves the machine to the stopped state.
  • A machine shut down abnormally starts automatically as soon as its storage is ready — triggered by an event rather than a timer. Previously, the only automatic recovery pass ran once when storage started: a machine that crashed afterward remained stopped. If a start fails because of a node failure, Center retries up to three times without clearing the "should be running" flag. If resources are insufficient, the machine retains the "should be running" flag, the reason is logged, and the start is not retried on a timer.
  • A stopped Edge router no longer starts again automatically a few seconds later. Center treated its own Edge stop command as a crash and immediately started the machine — preventing network ports from being added or removed after stopping the Edge router.

Storage pools

  • Stopping and moving a pool no longer fail with "pool is busy" when its virtual machines are running on other nodes. The service script did not touch machines from the same pool running on neighboring nodes (their disks are served over the network from the owner) — the pool remained busy because it was still in use, export failed, the pool remained on the original node, and the remote machines continued running. Before stopping the service, Center now shuts down these machines on other nodes itself and only then stops the service; the same applies when moving a pool. If any machine cannot be shut down, the operation does not start at all and returns a list of blocking machines with their nodes — the service remains operational.

Inventory

  • The virtual machine list no longer repeats the same machine multiple times. A machine appeared as many times as the user had roles in its VDC, so external systems that built their own directories from the list received duplicates and could not produce an inventory report. The set of machines in the list has not changed — only duplicates have been removed.

3.1.0 — September 3, 2026​

This release focuses on resilience. The main addition is live migration: a running machine can now be moved to another node without stopping. All other changes aim to keep Center and the nodes consistent about what is happening to a machine: an operation interrupted halfway through no longer leaves a machine locked, migrating, or "creating" forever, and the VDC quota finally counts machine disks and storage volumes together.

Highlights​

  • Live VM migration — moving a running machine to another node without shutting it down, and moving a stopped machine's data between storage locations through a single method. Migration progress is available through a separate status request: phase, percentage, and reason for failure.
  • Unified VDC capacity accounting — the space quota counts storage volumes alongside machine disks. The used space shown on screen now matches the value used to reject an operation.
  • Transition state timeouts — a machine no longer remains in the "starting" or "migrating" state indefinitely: each state has its own time limit, after which the machine enters the corresponding failure state.
  • A resubmitted request is not executed twice — the same ID returns the same response instead of running the operation again.
  • Hardware inventory works again — physical disk and network interface lists are populated, including NVMe drives connected without an enclosure.

Upgrade considerations​

  • Access credentials for the node controller channel are now required on every cluster. The dispatcher will not start without them — check the settings before upgrading.
  • Active sessions are terminated. Session tokens and forced password change tokens now use a cryptographically secure random source; users must sign in again after the upgrade.
  • Hardware inventory must be forced to run once so that disk and network interface lists are populated with current data.
  • VDCs with storage volumes will show higher used space and quota utilization — this corrects the accounting rather than reflecting increased consumption. Starting existing machines still works as before: users can power on their own stopped machines even when volumes have consumed the quota.
  • Database schema changes are applied automatically during the upgrade. The previously announced manual step involving a column in the VM runtime status table is no longer required — the change has been moved to a separate migration.
  • The service now starts even if the database contains a record of a schema change that is absent from the installed version: the record is logged as a warning. A failure of the schema change itself still prevents startup.

Added​

Virtual machines

  • Live migration: moving a running machine to another node (the machine must be in the "running" state) and moving a stopped machine's data to another storage location — a single method handles both tasks, with a parameter selecting the procedure. The operation is available to the Cluster master role.
  • Migration progress is read through a separate status request: state, phase, percentage, source and target node or pool, and reason for failure. Until migration is complete, operations that could interfere with it — stopping, changing the configuration, and unlocking — are rejected with a clear error; reading machine data remains available.
  • Transition states (starting, stopping, creating, deleting, suspending, resuming, migrating, restoring) now have time limits — from 15 minutes for starting to 6 hours for migration and restoration from backup. When the limit expires, the machine enters the corresponding failure state, and the reason is recorded in the service log and the machine's state history. A successfully created machine that has never been started is not subject to this rule.

VDCs and storage

  • A VDC's space limit cannot be reduced below actual usage: the attempt is rejected with the requested limit and current usage specified, and the value is not applied. The limit can still be removed entirely.
  • The storage screen shows used space and size for each volume — the data for the capacity panel hidden in 3.0.4. If the storage controller is unavailable, used space is shown as blank, but the storage card still opens.
  • Storage now has a visible teardown state: it indicates that an interrupted VDC deletion must be retried. Successful teardown clears the state.

Physical disks

  • The physical disk list now includes NVMe drives connected directly, without a drive enclosure — previously, the list remained empty on nodes using only NVMe drives. For these drives, the enclosure and its device are shown as "no value": this indicates that fault indication and locating the drive (LED) are unavailable — the enclosure provides the indicators. Health is shown as unknown because it cannot be measured without an enclosure.

Cluster

  • The cluster state reports that settings have changed and the service must be restarted. Settings are read once at startup and are not reloaded at runtime, while the cluster state showed their current database values — a changed maximum disk size, for example, appeared to have been applied even though validation still used the previous value. The discrepancy is now visible as a separate flag, and the list of changed settings is recorded in the service log.

Changed​

  • The VDC space quota counts storage volumes alongside machine disks. Previously, these two parts were unaware of each other: a tenant that had consumed the entire quota with volumes could still freely add and expand machine disks.
  • Deleting a mapped volume no longer requires unmapping it first — the mapping is removed automatically, and the volume is deleted in a single action. If the controller still rejects volume deletion (for example, because of snapshots or clones), the volume remains unmapped: the mapping can be restored through a separate action.
  • The storage volume card opens faster: two storage requests run concurrently rather than sequentially. If storage does not respond, the wait time is halved.
  • A disk connected to multiple nodes at once (dual-port NVMe) is shown on the node that currently owns its pool — the same node on which the pool appears in the pool state view, with the device name used on that node. A disk that does not belong to any pool is still shown on the node that last reported it.
  • If a node responds with "machine already suspended" or "machine already running", the operation is considered complete: the operator sees success rather than an error when the result has actually been achieved. Stopping a machine already worked this way.
  • Methods for setting limits — network limits for machines and Edge routers, and disk limits for machines — accept an empty value as "unlimited" and distinguish it from zero. Previously, an empty value either caused an error or was silently replaced with 0.
  • A resubmitted request is not executed a second time. If the original request has already received a response, the same response is returned to the same user; if it is still running, a "request already being processed" error is returned. A request using another user's ID does not receive that user's response.

Security​

  • Fixed breaches of isolation between VDCs in several methods. VDC administrators can no longer create cluster network types — Routed and Q-in-Q: these networks give the tenant access to the shared cluster segment and, as required by the role model, are available only to the Cluster master role. In the OS profile list, VDC administrators, users, and observers no longer see private images belonging to other VDCs — only shared images and images assigned to their own VDC. Viewing a role card is now available only to the Cluster master role. The permission changes are applied automatically during the upgrade.
  • Session tokens and forced password change tokens are now resistant to brute-force attacks — they are generated from a cryptographically secure random source.
  • Password brute-force protection can no longer be bypassed with concurrent sign-in attempts. Previously, a batch of parallel requests using the same username could check significantly more passwords than the threshold allowed without locking the account; the failure counter and security log records understated the number of failures.
  • Standard security log integrity checks no longer produce false positives on large logs or after automatic archiving of old records. Actual record tampering is still detected.
  • VM configuration checks no longer report false discrepancies: on healthy machines, on machines using the old disk controller type (all legacy Windows machines), or on machines running outside the node that owns their pool. Previously, this caused a stream of false integrity violation events with the highest urgency level in the security log.
  • Access denied to Edge functions when the corresponding feature is disabled is once again recorded as a separate event in the security log — recording stopped working after audit unification and has now been restored.
  • An incorrectly specified severity level in security alert settings no longer leaves email alerts enabled: the settings are applied in full or not at all. The same applies to log archiving settings.
  • A database failure no longer exposes internal details — table and constraint names remain in the dispatcher log.

Fixed​

Machine state and operations

  • Restarting a machine no longer clears its "should be running" flag. Center treated the intermediate shutdown that occurs during every restart as a guest shutdown and recorded the machine as stopped by the administrator — after a node failure, the machine was not recovered automatically, and suspension was rejected with "machine is not running". Guest shutdown is still recognized and moves the machine to the stopped state.
  • A running machine is no longer marked as stopped because of delayed node events. If a node was disconnected from Center and sends accumulated events after reconnecting, outdated events no longer overwrite the current status.
  • Failed machine creation no longer leaves it in the "Creating" state forever: the machine enters "Creation failed" and is unlocked. The same fix applies to cloning and Edge creation.
  • Failed machine deletion no longer leaves it in the "Deleting" state — the state before deletion is restored, and the operation can be retried.
  • Suspending a stopped machine is rejected immediately and changes nothing in the database. Previously, the operation was accepted for any machine, and if the node rejected it, Center marked the machine as running and lost its node association — this could only be fixed by editing the database. The same fix applies to resuming a machine.
  • A failed start, stop, or restart no longer leaves a machine in the inconsistent state "running, but no node specified".
  • A failed machine setting change no longer causes a discrepancy with the setting on the node: the previous value is restored on any failure. This applies to memory size (balloon), CPU priority, virtual CPU class, disk label, and Edge port rate limits.
  • A message broker connection failure no longer leaves a machine locked forever: the busy flag is cleared automatically before the operator sees the error. This applies to taking a snapshot, rolling back to a snapshot, deleting a snapshot, adding, resizing, and deleting a disk, disk and network rate limits, and deleting an Edge router.
  • Two concurrent requests for the same machine no longer both proceed: only one can acquire the machine, while the second immediately receives a "machine is locked" error and sends nothing to the node.
  • An operation on a machine no longer clears a lock set by another operation that is still running.
  • A single request no longer receives two responses: protection against concurrent processing remains in place regardless of the operation's duration.
  • Automatic recovery of machines no longer sends a second start command to a machine whose previous start command is still running. Cluster service machines are consistently excluded from both status updates and automatic recovery.
  • Starting a machine again or recovering it automatically when Center considers it stopped but it is actually running no longer triggers a second start or corrupts its state in the database.
  • Node selection for starting a machine and node memory capacity checks now produce consistent results: a start is no longer rejected with a cluster memory shortage message when memory is actually available. Resuming a suspended machine correctly accounts for memory that has been freed.
  • Disk and network port rate limits set on a running machine once again reach the machine and persist after a restart. Edge port rate limits can be set again.

Machine migration

  • Stop, restart, and suspend commands for a machine moved to another node without shutting down reach the node where the machine is actually running. Previously, the command went to the node hosting the machine's storage.
  • After a running machine is successfully moved to another node, it is no longer shown as stopped or "stopping": while migration is in progress, migration itself controls the machine's state.
  • A machine moved without stopping to the node that owns its storage is no longer listed as running remotely — it runs locally on that node.
  • Migration between storage locations can no longer report success while losing the machine: source data is deleted only after the configuration has been confirmed as applied at the destination. Redelivery of the same response from the receiving node no longer deletes the source data a second time.
  • Two consecutive migration requests for the same machine no longer start two migrations.
  • A rejected migration request reports the actual reason: an invalid migration type is rejected as an invalid type, and a request for a nonexistent machine reports that the machine was not found.
  • Interrupted cloning no longer leaves a phantom machine — a record with all its reserved addresses and console ports that exists on no node.
  • Interrupted machine import no longer leaves the machine partially imported.

Pools, disks, and inventory

  • After a pool moves to another node, the interface shows the node where the pool is actually running: Center checks the owner against the cluster state once a minute. A pool that is not running on any node is shown on its last known node.
  • Pool usage and snapshot sizes are updated again. Nodes were sending this data through a new channel, but Center did not understand it and silently discarded it — causing machine creation with automatic pool selection to return "pool not found".
  • The cluster's physical disk list is populated again: hardware inventory stopped at the very beginning and recorded nothing — no disks or enclosures, physical network interfaces or link aggregation interfaces, or SMBIOS data — while reporting success. Network interface collection has also been fixed separately.
  • A physical disk no longer gets stuck in the "online in the cluster" state: during inventory, Center updates this flag to match the actual state on the node, and the disk becomes available for operations again.
  • A delayed response to a physical disk operation no longer clears protection already set by the next operation on the same disk.

VDCs, storage, and networks

  • A VDC with a stalled volume reservation can be deleted again. An incomplete reservation (no response received from the controller) was treated as a real volume and permanently blocked deletion.
  • VDC quota space reserved by incomplete storage or volume creation is no longer lost forever: the reservation is released automatically.
  • A failure at the final step of deleting a VDC with storage no longer leaves remnants that cannot be deleted.
  • Deleting a storage volume no longer fails if its mapping has already been removed on the storage side: a "LUN does not exist" error is recognized as work already completed.
  • Available space on the volume card means the volume's own remaining space rather than the pool's free space.
  • Creating or modifying an iSCSI CHAP set without a mutual username and password pair is rejected immediately with a clear error rather than later by the node. Renaming the group or changing only the password preserves the mutual pair.
  • Renaming a storage initiator group or authentication group to a name already in use is rejected with a clear error before contacting the controller. The API client can distinguish a disabled Unified Storage feature, an infrastructure failure, and an input error by the response code.
  • Network creation is no longer rejected with the network removed from the database when it has already been created on the nodes: each response is counted for a specific node. The same applies to network deletion and modification.
  • Failed Edge deletion no longer destroys it irreversibly: nothing irreversible happens until machine deletion is confirmed, and the Edge router and all its rules remain in place.
  • A failure to send a command to a node no longer leaves an operation listed as running. This applies to filesystem and pool operations, starting, stopping, restarting, deleting, and configuring Edge routers, and configuring iSCSI for VDCs.

Users and API

  • Specifying a nonexistent role when assigning a role returns a clear "role not found" error instead of a database failure; "role already assigned" and "cannot assign a role to a system user" errors have different codes.
  • The API request log is populated again on clusters where its table was configured manually — and retrieving a task result by ID works again as well. On those clusters, it previously returned "task not found" for every request. Protection against repeated request execution has also begun working there. A failed log write appears as a separate entry in the service log, and the frequency of failures is summarized every five minutes.

3.0.5 — July 31, 2026​

A major release. A library of reference OS images is now available, with external sources and import support. Physical disks now have a complete lifecycle (spares, claiming disks in the cluster, replacing failed disks), virtual machines can now be cloned, and disk data can be copied to another cluster. The security log has also been strengthened: it now includes events from the nodes themselves. User-visible changes are listed below.

Highlights​

  • OS image library — a catalog with shared and private images, external source connections, import with automatic distribution across storage, and removal of an image from the entire cluster in a single operation.
  • Physical disk lifecycle — spare disks (Hot Spare), claiming and unclaiming disks in the cluster, replacing a failed disk in a pool, and checking pool health with a single request. These operations are available only to the cluster's primary administrator.
  • VM cloning — an instant copy of a stopped machine on the same storage with the same configuration.
  • Cluster-to-cluster backup — full and incremental copying of VM disk data to another cluster.
  • Security log on nodes — SSH sign-in, kernel parameter changes, local accounts, node reboot, and node kernel panic.

Breaking changes​

  • An OS image is identified by a global ID instead of a short number. Image lists, machine cards and lists, machine creation, and transfer from the import area use the new ID — API clients must send and expect it in the new format. Existing machines retain their image associations.

Added​

OS image library

  • An image can be shared across the entire cluster or private — visible only to its VDC. Previously registered images continue to work: regular images become visible to the entire cluster, while previously private images remain private.
  • Each image is tracked by its lifecycle stage, presence on storage, integrity checksum, and version number.
  • External image libraries: the administrator registers a source by its address and can view a list of sources available to them. Unsafe and special-use addresses, as well as unencrypted URLs without explicit authorization, are rejected with an explanation.
  • Importing an image from a connected library: the file is downloaded once, its integrity is checked, and the image is then distributed across storage. Import progress is visible in real time — the overall completion percentage and the percentage for each storage location.
  • A unified image management list shows the complete cluster catalog, including images still being downloaded, and each image's origin — the library from which it was imported.
  • Before deleting an image, its dependencies can be viewed: which nodes and storage locations contain descendants and which machines run on them. Deleting an image from all nodes and storage is a single operation and requires explicit confirmation that it is irreversible.

Physical disk management

  • Spare disks (Hot Spare): a free disk can be marked as a spare, and the mark can be removed. The disk's role is updated after the node responds.
  • Claiming and unclaiming a disk in the cluster (Claim/Unclaim): a raw disk is brought online in the cluster and taken offline again; it is not added to a pool.
  • Replacing a failed disk in a pool: before starting, the system queries the node and does not begin the replacement if the replacement disk is not free.
  • Storage pool health with a single request — for the entire cluster or for one node. Nodes are queried in real time, and an unavailable node is marked with a separate state.
  • A single request for the node's disk list shows each disk's role (free, partitioned, in a pool, spare) and the "online in the cluster" flag.
  • Center receives disk events from nodes — a newly connected disk, automatic replacement of a failed disk with a spare, and degradation.

Virtual machines

  • VM cloning: a copy of a stopped machine with the same configuration — CPU, memory, disks, and network. Disks are cloned instantly and consume almost no additional space. The clone is created on the source machine's storage.
  • A machine with clones cannot be deleted until the clones are deleted: a list of blocking clones is displayed instead of a storage error.

Storage

  • The All volumes screen: the cluster administrator can view volumes from all VDCs in a single table with filters and pagination.
  • The protocol access overview screen: five consistent figures for the entire cluster on one screen.
  • The iSCSI portal group list and cards show the pool and VDC; the card also shows the endpoint address.

Backup

  • Copying virtual machine disk data to another cluster — full and incremental.

Security log

  • Events on cluster nodes: SSH sign-in (successful and failed), node kernel parameter changes, and creation and deletion of local accounts.
  • Node system events: startup, normal and abnormal shutdown, and kernel panic — with the source node identified.
  • VM configuration checks now record both the check itself and its verdict. A detected discrepancy from the reference configuration is recorded as a separate integrity violation event with the "requires immediate response" severity: it is included in the critical event counter and email alerts.
  • VM start, stop, suspend, and resume events now include the reason for the action; virtualization software start and stop events include the reason for the stop.
  • Abnormal termination of the virtualization software (process termination, crash, power failure of the management machine) no longer goes unnoticed.

Improved​

  • Image import is more reliable: any failure marks the image as "failed", which is visible in the catalog — import no longer stalls silently.
  • Protection when working with external image sources has been strengthened: access to internal and special-use addresses is blocked regardless of how the address is represented.
  • Image data from the source — version, sizes, checksum, and timestamp — is validated before import.
  • VM creation without an explicit storage selection is smarter: if an image is distributed to only some storage locations, the system automatically selects a suitable one.
  • Image visibility scopes are now consistent: the profile reference list and the management list show the same set of images.
  • VM and storage operations for which the node never responds no longer remain pending indefinitely — they terminate when the timeout expires.

Fixed​

  • Operations no longer disappear without a trace when the message broker restarts or the dispatcher terminates abnormally. A redelivered request is not executed a second time: a synchronous call receives a "request already exists" error and can be retried with a new ID.
  • Starting a VM can no longer overload a node by bypassing checks. Automatic recovery of machines after a node returns to service distributes them across the cluster rather than placing them all on one node. Resuming a suspended machine is rejected if the node has insufficient memory or the VDC quota is exceeded — just like a regular start.
  • Fixed an incorrect subnet mask on new and restarted VMs — the guest is once again accessible from outside over the network.
  • Fixed a breach of isolation between VDCs: an administrator of one VDC can no longer read or modify the properties of a disk in another VDC by knowing its internal ID.
  • Users can no longer move another user's VM into their own VDC from a VDC they cannot access.
  • Fixed an error that prevented a user with an administrator role in their VDCs from seeing the resource tree.
  • Fixed discrepancies between the database and cluster nodes when adding and removing a network adapter and when deleting and creating a network.
  • Fixed a discrepancy in the security log: clicking a critical event badge no longer shows an empty list.

3.0.4 — July 16, 2026​

A major release: networks now have full IPv6 support, virtual data centers (VDCs) have their own block storage accessible over iSCSI, and a running VM's configuration can now be checked against the reference configuration in a single action. User-visible changes are listed below.

Highlights​

  • IPv6 (dual-stack) — networks and ports work with IPv4 and IPv6 simultaneously; everything that previously accepted an IP address or CIDR now supports IPv6 alongside IPv4.
  • VDC storage (Unified Storage) — the complete block storage lifecycle within a VDC: enabling storage, an iSCSI target, volumes, mapping volumes to clients over iSCSI, initiator and portal groups, and CHAP authentication — all managed through the web interface.
  • VM configuration checks — checking a running VM's actual configuration against the reference configuration in a single action, with every check recorded in the security log.

Added​

IPv6 (dual-stack)

  • Networks can be created with IPv4 and/or IPv6 addressing: specifying either an IPv4 or an IPv6 range is sufficient when creating a network. A separate default gateway can be specified for IPv6 — the system checks that it belongs to the network.
  • Up to eight IPv6 addresses can be assigned to a VM or Edge port when creating a VM, adding a network adapter, or creating an Edge router. If no IPv6 address is specified, behavior remains unchanged.
  • Separate port flags control which address families (IPv4, IPv6) are used to allocate addresses.
  • IPv6 addresses are returned in API responses alongside IPv4: in network and VDC network lists, VM cards and lists, the Edge card, and all address pool operations.
  • IPv6 values are accepted wherever only IPv4 was previously accepted: Edge firewall and NAT rules, VM DNS servers, and user remote access settings.

VDC storage (Unified Storage)

  • Enabling storage in a VDC: the administrator specifies a name and a pool, and the system creates the root storage area. One storage instance per VDC.
  • Configuring an iSCSI target with a single command: the target name is derived from the storage name, and the target is created on the pool controller. Target details show the portal group, the number of active sessions, and the assigned CHAP group.
  • Volumes: creation with VDC quota validation, listing, and deletion. The volume details card shows parameters and current metrics — used and available space, compression and deduplication ratios, and mapping status.
  • Mapping a volume to clients over iSCSI (Map): the volume is assigned to an initiator group under the specified LUN number and is visible only to that group. The reverse operation (Unmap) unmaps the volume while preserving the group and target.
  • Initiator groups — lists of clients (IQNs) and networks allowed to access volumes: creation, viewing, membership changes, and deletion. Changes to group membership immediately affect access to all its volumes.
  • iSCSI portal groups: creation, viewing, and deletion. A group attached to a target cannot be deleted.
  • CHAP authentication: named sets of accounts (multiple "user/secret" pairs, including mutual CHAP), assignment to a target, and membership changes. Secrets are not displayed after creation. A CHAP group can be specified when creating a target.
  • The VDC details page in the web interface now has a Storage tab: a storage overview (properties, protocol status, capacity, configuration form), a volume list, and an iSCSI section. Details pages have been added for volumes (with Map / Unmap actions), targets (with CHAP user management), and initiator groups. Storage is enabled through a step-by-step wizard, and a Unified Storage step has also been added to the VDC creation wizard.
  • The entire subsystem is controlled by a single cluster flag and is disabled by default.

Virtual machines

  • VM configuration checks: a new action compares a running VM's actual configuration (as seen by the hypervisor) with the reference record in the vStack Center database and returns a "match / mismatch" result with the number of discrepancies. Every check is recorded in the security log with an end-to-end request ID. In the web interface, the result is available in the Config integrity window on the VM page.

Security

  • Effective sign-out: a new action immediately terminates the user's current session or, optionally, all their sessions on all devices; the previous sign-in is no longer valid. Every sign-out is recorded in the security log — who, when, and from where.
  • A cluster toggle for Edge functionality. When the toggle is disabled, vStack Center rejects all Edge router operations, including viewing lists and cards, and records every attempt in the security log. In the standard distribution, the toggle is enabled and behavior remains unchanged. Edge routers that are already running continue to operate; vStack Center stops managing them.

Changed​

  • Deleting a VDC with storage enabled now cascades: the system sequentially removes volume mappings, deletes the target and disk partition, and then deletes the VDC itself. If any volumes remain in storage, deletion stops with a request to delete them first.
  • If the node running a VM is unavailable, VM operations now return a separate "node unavailable" error — previously, this situation returned a generic error without a reason.
  • The session cookie is now sent only over HTTPS: the HttpOnly and SameSite=Strict attributes are now joined by Secure.
  • Handling of the VM console access token has been tightened: it no longer appears in service logs, has a limited lifetime (5 minutes by default), and is strictly single-use; the token's service files are inaccessible to other users on the node.
  • The VDC list has been redesigned as a flat table with a storage state filter. The VDC overview has been updated: resource utilization rings, quotas, roles, and settings.

Fixed​

Network

  • Fixed the "network is not assigned to this vDC" error that could occur when creating a VM even though the network was assigned correctly.
  • If network creation fails on a node, a record of the nonexistent network no longer remains in the database — the network does not appear in lists.
  • A range without a netmask (for example, 192.0.2.1 instead of 192.0.2.0/24) is now rejected with a clear validation error — previously, the request ended with an internal error.

Virtual machines

  • Fixed an intermittent error when creating a VM under concurrent load: recording a disk and assigning it to the VM could fail with an internal error even though all parameters were valid.
  • Fixed VM status delivery: the status displayed in the interface no longer reverts to an outdated status after events from the node.

Security log

  • When multiple dispatcher instances ran concurrently, log records could compromise hash-chain verifiability. Records are now serialized, and the chain remains verifiable.
  • Fixed enrichment of log records with VDC storage information — the pool name is added to records again.
  • In the log interface, the filter button no longer disappears when fewer than five events remain after filtering; severity tag colors have been made consistent.

Storage

  • Storage disk partition names are now unique across VDCs — enabling storage with the same name in different VDCs no longer causes a conflict.
  • VDC administrators now have access to the iSCSI portal group list, without which they could not map a volume even though they had permission for the action itself.

For a complete description of API changes, see the vStack Center operations documentation: the "Network management", "VDC storage", "Virtual machines", and "Access management" sections.

3.0.3​

This release focuses on access. The role model has moved from a fixed association with role numbers to scoped privileges, with custom roles and two new fixed roles. Sign-in is now protected by a password policy and brute-force protection. The management layer has also moved to the current cluster dispatcher architecture.

Highlights​

  • Privileges instead of role numbers. Access is determined by a scoped privilege rather than the user's role. Checks are performed centrally for every method. Existing assignments have been migrated automatically from the old model.
  • Custom roles. The cluster administrator builds a role from privileges and assigns it within a VDC. Custom role numbers start at 10000; fixed roles are protected against modification and deletion.
  • The Security Admin role (ID 6) — cluster scope, for auditing only: viewing, filtering, and exporting the security event log, and checking integrity. It has no access to machines, networks, users, or infrastructure. The role meets FSTEC (Russia's Federal Service for Technical and Export Control) requirements for a security administrator.
  • The VM Developer role (ID 7) — VDC scope: creating machines and editing their configuration, including disks and network adapters. This role cannot start, stop, or delete machines, access the console, or work with snapshots.
  • Password policy and brute-force protection. Password requirements are configurable, failed attempts are counted, and the account is locked when the threshold is reached.
  • Automatic node selection when starting a VM. A machine using NVMe disk mode with no explicitly selected node starts on the least loaded node in the ONLINE state. A machine using virtio-blk still starts only on the node that owns its pool.

Added​

Roles and privileges

  • Custom roles: create, modify, delete, and view. Management is available only to the Cluster Master role. The role list shows the creator of each custom role.
  • The "object creator" scope: a VDC administrator can view and manage their own networks and Edge routers even outside their VDC.
  • 24 Own privileges for access to objects owned by the user: 8 for networks and 16 for Edge routers.
  • Read access to the access registry: role-to-privilege mappings, the privilege registry with categories and scopes, and category and scope reference lists. Available to all seven fixed roles.

Sign-in and accounts

  • Configurable password requirements: minimum length, uppercase letter, lowercase letter, digit, special character, and prohibition on matching the account name.
  • Reuse of the current password is prohibited.
  • A failed sign-in attempt counter with automatic locking when the threshold is reached and automatic unlocking when the lock period expires. A zero lock period makes the lock permanent: only the cluster administrator can remove it.
  • Forced password change: at first sign-in or at the administrator's discretion, a single-use token valid for 5 minutes is issued instead of a regular session. It allows only changing the user's own password and reading security settings.
  • Manual account unlocking by the cluster administrator.
  • Failed sign-in responses are more informative: an incorrect password response includes the number of failed attempts, the threshold, and the time of the first failure; a temporary lock response includes the time when the lock expires.
  • User cards and the user list show the failed attempt counter, the time of the first failure, the lock period, and the mandatory password change flag. An expired lock is removed when the record is read.

Virtual machines

  • Machine cards and the machine list show the node even after the machine stops.
  • A specific storage pool can be selected when creating a machine; if none is specified, the pool is selected automatically.
  • The cluster overview shows allocated and available memory at the node level.

Improved​

  • Data validation when creating and modifying a VM: memory alignment to 4 KiB, the upper memory limit based on the cluster maximum, the hostname in the guest section, and the SSH password sign-in toggle. Disk resizing is once again checked against the cluster maximum.
  • The OS profile for the Edge service machine is now a cluster option rather than being hard-coded in the template.
  • Passwords are hashed in the dispatcher itself rather than by database functions.

Fixed​

  • Fixed user-visible errors in asynchronous operation handling.
  • Concurrent password changes for the same user no longer cause a race condition. The forced password change token is now truly single-use: a concurrent request with the same token is rejected. After a successful password change, all previously issued sessions for that user are terminated.
  • Errors for nonexistent objects no longer appear as permission errors. Starting, stopping, and restarting a nonexistent machine now return "machine does not exist" rather than "machine is outside your visibility scope". Disk bandwidth limit errors also distinguish between a nonexistent machine, a disk not attached to the machine, and a machine outside the visibility scope.
  • A machine history request with a nonexistent ID returns a clear error rather than an empty list that could not be distinguished from "no history yet".
  • Assigning or removing a role for a nonexistent user returns "user not found" instead of an unclear database error.
  • VDC names and descriptions that are too long are rejected with a clear validation error rather than a database error. Length is measured in characters, so Cyrillic text is measured correctly.
  • Edge routers with no assigned ports are visible in the list again.
  • Address usage by VDC is calculated correctly: the cluster administrator receives results for the specified VDC, a user without a VDC receives an empty result, and another user's VDC no longer returns data.
  • Physical disk inventory no longer creates duplicate records because of spaces in the serial number received from the node agent.
  • The cluster overview accounts for the memory and CPUs of machines moved between nodes.

3.0.2​

Added​

  • Basic operations for managing the cluster, nodes, and virtual machines.

See also​