fix(pvc-artifact): relicense CDI-derived files with recognized header by Isteb4k · Pull Request #2629 · deckhouse/virtualization

Isteb4k · 2026-07-09T17:45:04Z

Description

The 22 CDI-derived Go files under images/pvc-artifact carried a bare
Copyright <year> The CDI Authors. header that the DMT license linter does
not recognize. This adds the standard Flant JSC Apache 2.0 header (recognized by
the linter) while retaining the original CDI copyright notice, as required by
Apache License 2.0 §4(c).

The original attribution — Copyright <year> The CDI Authors — is kept inside
the Apache header block comment, right after limitations under the License.,
together with a note crediting the Containerized Data Importer (CDI) project as
the origin. The same treatment is applied to the CDI-derived
images/dvcr-artifact/pkg/monitoring/prometheus.go.

The attribution is placed inside the /* */ block (not as a trailing //
comment) on purpose: the DMT license parser inspects .go headers with the //
line-comment style before the block style and treats the first // line
starting with Copyright as the license, which then fails to match any known
template. Keeping it in the block comment lets the linter still match the
recognized Flant JSC header as a substring while preserving the upstream notice.

Why do we need it, and what problem does it solve?

The DMT license linter rejects the bare CDI headers with "license header does
not match any known license", which fails the DMT check on every PR touching
pvc-artifact. The Flant JSC header is recognized by the linter, and retaining
the CDI copyright notice keeps the vendored code compliant with Apache 2.0.

What is the expected result?

The DMT license check passes on images/pvc-artifact and images/dvcr-artifact;
no file reports "license header does not match any known license", and the
original CDI copyright notice is preserved.

Checklist

The code is covered by unit tests.
e2e tests passed.
Documentation updated according to the changes.
Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: core
type: chore
summary: Relicense CDI-derived pvc-artifact files with the recognized Apache 2.0 header while retaining the original CDI copyright notice.
impact_level: low

Signed-off-by: Dmitry Rakitin <dmitry.rakitin@flant.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Changelog v1.9.3 Signed-off-by: deckhouse-BOaTswain <89150800+deckhouse-boatswain@users.noreply.github.com> Co-authored-by: universal-itengineer <universal-itengineer@users.noreply.github.com>

Signed-off-by: Valeriy Khorunzhin <valeriy.khorunzhin@flant.com>

During a restore the VM is stopped inside the maintenance window: its KVVMI and then the KVVM itself are deleted. Bringing the VM back up afterwards relied on an implicit side effect — the recreated KVVM getting RunStrategy=Always at creation time. That path is racy and only covers the always-on policies. --------- Signed-off-by: Daniil Antoshin <daniil.antoshin@flant.com>

) Signed-off-by: Maksim Fedotov <maksim.fedotov@flant.com>

Signed-off-by: Maksim Fedotov <maksim.fedotov@flant.com>

Add validation to getIPerfClientReport verifying that the iperf client session spans the virtual machine migration: start time before migration start, end time after migration end, and no more than one zero-byte interval during the process. Signed-off-by: Dmitry Prytkov <dmitry.prytkov@flant.com>

…refix (#2594) The d8 v ansible-inventory command read host variables from the bare provisioning.virtualization.deckhouse.io/ prefix, while the virtualization-provisioner module reads them from the separate vars.provisioning.virtualization.deckhouse.io/ prefix. The same VM annotations produced different inventories depending on the tool. Read host variables from the vars. prefix to match the module. Groups still come from provisioning.virtualization.deckhouse.io/groups. Update the command help, usage examples and the ansible-inventory FAQ. Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com>

…d manually (#2596) fix(vm): fix VM stuck until the child KVVMI in Failed phase is deleted manually Signed-off-by: Yaroslav Borbat <yaroslav.borbat@flant.com>

Virtualization has no primitive to manage a group of identical virtual machines whose count changes over time. Every "I need N identical VMs and the number varies" scenario — CI runner fleets, VDI desktop pools — has to be solved with orchestration outside the platform: users write their own controllers/scripts to create and delete VirtualMachines, watch their number, recreate lost ones and clean up their disks. This duplicates logic and is error-prone around races and node failures. This PR introduces VirtualMachinePool (paid editions only, EE/SE+): a namespaced resource that declaratively keeps a requested number of identical VMs and integrates with kubectl scale, HPA and KEDA through the standard scale subresource. Its template is an ordinary VirtualMachineSpec, so a replica is no different from a manually created VM. The feature is complete and covers: Replica management — keeps the requested number of identical VMs, replaces lost ones, and reports state in status (replicas, readyReplicas, selector, conditions). It is cache-lag-safe (ReplicaSet-style expectations), so a lagging informer cache cannot double-create replicas. Scale-down policy — NewestFirst / OldestFirst choose which replica leaves on anonymous scale-down via scale; Explicit forbids anonymous shrink through a webhook, so for "busy" workloads (CI runners, VDI) replicas can only be removed by address. Addressed removal — the scaleDownWith subresource deletes named replicas and shrinks the pool by that count, instead of letting the controller pick victims. In-place template propagation — editing the template rolls the change out to existing replicas; disruptive changes wait for a restart and are surfaced via status.restartPendingReplicas. Reusable disks — per-replica disks are described in virtualDiskTemplates with a reclaim policy: Delete disks belong to the VM and are removed with it; Retain disks belong to the pool, outlive the replica and are reused on the next scale-up, with an optional warm buffer (keep) and TTL garbage-collection. The resource is available only in paid editions, gated behind the VirtualMachinePool module feature gate (default off, locked off in CE). The API/CRD installs in every edition, but the controller self-gates on the feature gate, so the resource does nothing in CE. --------- Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com> Signed-off-by: Vladislav Panfilov <vladislav.panfilov@flant.com> Co-authored-by: Vladislav Panfilov <vladislav.panfilov@flant.com>

…ate (#2621) The VirtualMachinePool feature gate was an opt-in placeholder. As the feature has not been released yet, drop the gate before release so the resource is available in EE/SE+ out of the box and stays unavailable in CE — the same model as VolumeMigration/TargetMigration. Nothing to migrate: the gate never shipped. - gate becomes locked-on in EE/SE+, locked-off in CE (no user opt-in) - dropped from the user-facing featureGates enum - pool webhooks gated by edition in helm instead of the feature-gate list Controller/webhooks keep self-gating on the now-locked gate. Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com>

Adds: - liveMigration.systemNetworkName ModuleConfig field. When set, VM live-migration traffic is routed over the per-node interfaces of a SystemNetwork CR from the SDN instead of the default node network. - migrationiface controller resolves the per-node kernel interface name and writes it onto each Node as the annotation virtualization.deckhouse.io/migration-iface. virt-handler reads that annotation at startup and binds its migration proxy to the SystemNetwork's per-node IP. - ModuleConfig validator to check if SystemNetwork added to liveMigration.systemNetworkName exists. - New reason for VMOP if migration network is unavailable on nodes. --------- Signed-off-by: Daniil Loktev <lokt.daniil@gmail.com> Signed-off-by: Daniil Loktev <70405899+loktev-d@users.noreply.github.com> Signed-off-by: Vladislav Panfilov <97229646+prismagod@users.noreply.github.com> Co-authored-by: Vladislav Panfilov <97229646+prismagod@users.noreply.github.com>

Description Log in to the private RU registry in the release channels workflow and check module versions against registry.deckhouse.ru/deckhouse. Why do we need it, and what problem does it solve? Release channel checks need access to artifacts in the RU registry. This keeps the workflow and version check pointed at the registry that contains the expected release artifacts. --------- Signed-off-by: Nikita Korolev <nikita.korolev@flant.com>

…lose gaps (#2602) Sizing policy validation errors were confusing and, in some cases, missing. When a VirtualMachineClass sets per-core memory limits, the error reported the allowed values per CPU core, while users configure the total memory — so the suggested numbers matched nothing they could actually set. Messages now report the total memory to set for the current number of cores, name the field to change, and combine multiple violations into a single readable list. This also fixes cases where the policy was silently not enforced: the CPU cores step was never validated, and a memory / per-core minimum was ignored when no maximum was set. Signed-off-by: Pavel Tishkov <pavel.tishkov@flant.com>

* docs: add VM launcher update notes to release notes Signed-off-by: Vladislav Panfilov <vladislav.panfilov@flant.com>

Description Removes CDI (Containerized Data Importer) from the platform. Disk and image provisioning no longer goes through CDI DataVolumes — the module now owns the whole import pipeline: The VD/VI controllers create and track importer/uploader pods and target PVCs directly (new source/step pipeline instead of the DataVolume path). A new PVC populator controller populates target PVCs from DVCR; host-assigned PVC cloning uses nbdcopy; the clone strategy (snapshot vs host-assigned) is picked from the StorageProfile, cross-CSI PVC-to-PVC cloning is forbidden. The CDI importer sources are slimmed down into a pvc-importer image; import progress is streamed live from the target pod into the resource status. CDI deployments (cdi-operator, cdi-apiserver, cdi-controller, cdi-cloner) and their templates/RBAC are removed; a module hook cleans up CDI resources on upgrade while keeping the CDI config CRD for safe rollback to main. e2e: expanded block-device coverage with progress/quota observers, WFFC and cross-CSI scenarios. Bugs fixed along the way Progress & phases Import progress could jump backwards after an importer pod restart (metric reset to 0); it is now monotonic (c2a61a4). An optimistic "0%" surfaced as an intermediate Pending 0% status; Pending now reports no progress and the Pending→Provisioning transition is atomic (d122212). Progress flip-flopped between 50%/50.0%; percent formatting is now consistent (00b93a0). VirtualImage-on-PVC never streamed intermediate progress (hardcoded 0%→50%→100%) and under-reported the produced image size, breaking downstream PVC sizing; both now come from the importer pod (680608b). A busy importer /metrics endpoint could freeze Status.Progress for the whole scrape budget (d122212). Import pipeline Interrupted PVC imports were not resumed for already-created targets (b95b230). Importer pods for VI/CVI sourced from a VI-on-PVC always mounted the source as a block device, failing with FailedMount on volumeMode: Filesystem PVCs (b79920c). VirtualImage PVC auto-sizing tripped a false "insufficient size" check (7edb744); status.format was copied from source metadata instead of the actual PVC storage type (0fa1bcf). VirtualImage WFFC imports hung in the populator flow (0fb3661); smart-clone image PVCs were never bound (8cc0139). Clone snapshots set a VolumeSnapshotClassName picked by provisioner match, which the d8-snapshot-controller webhook could reject (d59b1e2); replicated PVCs now use the snapshot clone strategy (c2f69e1). pvc-importer inherited generic provisioning pod limits, throttling imports ~30% and risking OOMKill on huge images; limits raised to CDI parity (b50d7b2). Importer/uploader/bounder pods are labeled to be excluded from project resource quotas (d122212, and quota guards in 9b7fc55). A create rejection in a terminating namespace failed the reconcile instead of being surfaced on the Ready condition (c2a61a4). Migrations & VMOP The inbound migration limiter leaked slots of VMIs deleted mid-migration, eventually freezing all migrations cluster-wide (43e4f3c). Affinity changes of VMs with local (RWO) disks never triggered a placement migration: the handler required live-migratability and ignored StorageLiveMigratable (67c29ba). The workload updater kept creating evict VMOPs that the webhook was guaranteed to deny, flooding controller logs (f6b0ac0). Why do we need it, and what problem does it solve? CDI was a heavyweight third-party dependency (4 deployments, its own CRDs and RBAC) used only as a PVC provisioning backend. Owning the import pipeline removes the DataVolume indirection, gives accurate live import progress, allows to fix bugs directly, and cuts the CVE/maintenance surface of the vendored CDI codebase. What is the expected result? Creating VirtualDisks/VirtualImages from all sources (HTTP, containerRegistry, ObjectRef, upload, blank) works as before without any CDI components in the cluster; import progress is reported in the resource status. Upgrading from main cleans up CDI resources automatically; rollback to main remains safe. --------- Signed-off-by: Dmitry Rakitin <dmitry.rakitin@flant.com>

Bump the size of the VirtualDisk restored from a VirtualImage in the VirtualImageCreation e2e suite from 400Mi to 450Mi. The change is in the shared runVirtualMachineFromImageDisk helper (test/e2e/blockdevice/virtual_image_creation.go), so it covers every context that boots a VM from a restored image disk (from a VirtualDisk, from a VirtualDiskSnapshot, from a VirtualImage on DVCR/PVC). --- Signed-off-by: Dmitry Rakitin <dmitry.rakitin@flant.com>

Integrates the new bpfbridge network binding plugin (kubevirt side: deckhouse/3p-kubevirt#99) into the virtualization module and switches VM network interfaces to it, replacing the classic tap + veth + Linux-bridge datapath used for VM networks. Signed-off-by: Dmitry Lopatin <dmitry.lopatin@flant.com> Signed-off-by: Maksim Garmonov <maksim.garmonov@flant.com>

The DMT license linter rejects the CDI copyright headers on the code vendored into pvc-artifact ("license header does not match any known license"). Replace them with the standard Flant JSC Apache 2.0 header recognized by the linter and add a note crediting the Containerized Data Importer (CDI) project as the origin, matching the convention already used in images/dvcr-artifact. Signed-off-by: Dmitry Rakitin <dmitry.rakitin@flant.com>

…rror The vm-controller can transiently log "failed to release PVC protection: failed to remove finalizer ...: no new finalizers can be added if the object is being deleted" when the built-in pv-protection controller strips kubernetes.io/pvc-protection from a PVC being deleted concurrently. Add it to logFilter so it does not fail the e2e Virtualization-controller log check, alongside the existing vd-protection/pod-protection entries. Signed-off-by: Dmitry Rakitin <dmitry.rakitin@flant.com>

The DMT license linter parses .go headers with the // line-comment style before the /* */ block style and treats the first // line whose text begins with "Copyright" as the license, which then fails to match any known template. Putting the CDI attribution in a // comment therefore broke the check. Move the attribution (including the original "Copyright <year> The CDI Authors" notice, preserved per Apache License 2.0 section 4(c)) inside the Apache header block comment, after "limitations under the License.". The block still contains the recognized Flant JSC header as a substring, so the DMT linter passes, while the upstream copyright notice is retained. Apply the same treatment to images/dvcr-artifact/pkg/monitoring/prometheus.go. Signed-off-by: Dmitry Rakitin <dmitry.rakitin@flant.com>

The referenced upstream CDI file carries no copyright header, so no specific year can be retained from it. Credit "The CDI Authors" without asserting a year that is not present in the source. Signed-off-by: Dmitry Rakitin <dmitry.rakitin@flant.com>

The merge-base changed after approval.

Isteb4k and others added 17 commits July 7, 2026 13:46

docs: add release notes for v1.9.3 (#2604)

5e99874

Signed-off-by: Dmitry Rakitin <dmitry.rakitin@flant.com> Co-authored-by: Claude Fable 5 <noreply@anthropic.com>

Changelog v1.9.3 (#2573)

e132f73

Changelog v1.9.3 Signed-off-by: deckhouse-BOaTswain <89150800+deckhouse-boatswain@users.noreply.github.com> Co-authored-by: universal-itengineer <universal-itengineer@users.noreply.github.com>

fix(vm): reduce virt-launcher log volume (#2561)

1144772

Signed-off-by: Valeriy Khorunzhin <valeriy.khorunzhin@flant.com>

chore(ci): silence dmt mount-points and webhook-annotation checks (#2615

888698f

) Signed-off-by: Maksim Fedotov <maksim.fedotov@flant.com>

chore(ci): add sds-elastic e2e tests (#2608)

f4fcd9e

Signed-off-by: Maksim Fedotov <maksim.fedotov@flant.com>

fix(vm): fix VM stuck until the child KVVMI in Failed phase is delete…

2ae8bae

…d manually (#2596) fix(vm): fix VM stuck until the child KVVMI in Failed phase is deleted manually Signed-off-by: Yaroslav Borbat <yaroslav.borbat@flant.com>

docs: add VM launcher update notes to release notes (#2613)

53555c3

* docs: add VM launcher update notes to release notes Signed-off-by: Vladislav Panfilov <vladislav.panfilov@flant.com>

Isteb4k requested review from diafour and yaroslavborbat as code owners July 9, 2026 17:45

Isteb4k added this to the v1.10.0 milestone Jul 9, 2026

github-actions Bot assigned Isteb4k Jul 9, 2026

LopatinDmitr and others added 3 commits July 9, 2026 20:51

Isteb4k force-pushed the fix/pvc-artifact-license branch from 1a4f6d7 to 8374cdd Compare July 9, 2026 18:16

prismagod previously approved these changes Jul 9, 2026

View reviewed changes

Isteb4k dismissed prismagod’s stale review via 3966d29 July 10, 2026 14:41

Isteb4k force-pushed the fix/pvc-artifact-license branch from 3966d29 to 5a58636 Compare July 10, 2026 14:48

Isteb4k requested a review from prismagod July 10, 2026 15:00

Isteb4k force-pushed the fix/pvc-artifact-license branch from 4d0c681 to 464144a Compare July 10, 2026 15:05

prismagod previously approved these changes Jul 10, 2026

View reviewed changes

deckhouse-BOaTswain force-pushed the main branch from ecd65ac to a9c8af4 Compare July 16, 2026 17:28

deckhouse-BOaTswain requested review from fl64, goganat, nevermarine, universal-itengineer and z9r5 as code owners July 16, 2026 17:28

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(pvc-artifact): relicense CDI-derived files with recognized header#2629

fix(pvc-artifact): relicense CDI-derived files with recognized header#2629
Isteb4k wants to merge 22 commits into
mainfrom
fix/pvc-artifact-license

Isteb4k commented Jul 9, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

12 participants

Uh oh!

Conversation

Isteb4k commented Jul 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

Why do we need it, and what problem does it solve?

What is the expected result?

Checklist

Changelog entries

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

12 participants

Isteb4k commented Jul 9, 2026 •

edited

Loading