-
Story
-
Resolution: Unresolved
-
Undefined
-
None
-
None
-
Product / Portfolio Work
-
3
-
False
-
-
False
-
Not Selected
-
ToDo
-
-
-
Very Likely
-
0
-
None
-
Unset
-
Unknown
-
None
This issue tracks the upstream Velero GitHub issue #9194 which is part of the Velero v1.18 milestone.
Description
This is an issue for considering the changes in datamover in behavior that will be caused by go1.25.
go 1.25 is container aware of resources set. https://tip.golang.org/doc/go1.25
The default behavior of the GOMAXPROCS has changed. In prior versions of Go, GOMAXPROCS defaults to the number of logical CPUs available at startup (runtime.NumCPU). Go 1.25 introduces two changes: On Linux, the runtime considers the CPU bandwidth limit of the cgroup containing the process, if any. If the CPU bandwidth limit is lower than the number of logical CPUs available, GOMAXPROCS will default to the lower limit. In container runtime systems like Kubernetes, cgroup CPU bandwidth limits generally correspond to the "CPU limit" option. The Go runtime does not consider the "CPU requests" option. On all OSes, the runtime periodically updates GOMAXPROCS if the number of logical CPUs available or the cgroup CPU bandwidth limit change.
If a CPU limit is set in the node-agent-config ConfigMap for datamovers, this will start to become the default for kopia UploadPolicy.MaxParallelFileReads when set when migration to go 1.25 occurs.
This is in contrast to current behavior that will use the number of CPU cores of the node as the default unless datamoverConfig.ParallelFilesUpload is set.
Upstream Details
- GitHub Issue: https://github.com/vmware-tanzu/velero/issues/9194
- Status: Open
- Assignee: Lyndon-Li
- Labels: Area/Documentation, area/datamover, area/fs-backup
- Created: 2025-08-19T17:09:40Z
- Updated: 2025-09-19T06:03:45Z
This requires documentation of the decision in the datamover configuration.