Problem
When draining a node, there is no capacity validation on the target node before migrating VMs. This means:
- If the target node is already at capacity, migrations will fail one by one
- No aggregate check that the target can hold ALL VMs from the source
- No user feedback before starting the drain
Current Behavior
// drain.go:95-112 — Only checks node exists and is enabled
if !targetNode.Enabled {
return fmt.Errorf("target node is not enabled")
}
// No CPU/RAM/disk check on target!
The runDrain method (line 218) simply iterates VMs and calls migrateFn for each without verifying the target has capacity.
Expected Behavior
Before starting drain, calculate:
- Sum of CPU/RAM/disk of ALL VMs on the source node
- Compare against target node's available capacity (using same scheduler logic as VM creation)
- Reject with clear error if target cannot hold all VMs
Proposed Solution
Add a pre-drain capacity check in StartDrain handler:
// Pseudo-code
sourceVMs := listVMsOnNode(sourceNodeID)
totalCPU := sum(sourceVMs.CPU)
totalRAM := sum(sourceVMs.RAM)
totalDisk := sum(sourceVMs.Disk)
targetUsage := getNodeUsage(targetNodeID)
if targetUsage.CPU + totalCPU > targetNode.MaxCPU {
return error("target node insufficient CPU capacity")
}
// Same for RAM and Disk
Impact
Without this check, drains can:
- Fail silently mid-operation
- Overcommit target node resources
- Cause VMs to crash on the target after migration
Priority
High — This is a data integrity and reliability issue.
Problem
When draining a node, there is no capacity validation on the target node before migrating VMs. This means:
Current Behavior
The
runDrainmethod (line 218) simply iterates VMs and callsmigrateFnfor each without verifying the target has capacity.Expected Behavior
Before starting drain, calculate:
Proposed Solution
Add a pre-drain capacity check in
StartDrainhandler:Impact
Without this check, drains can:
Priority
High — This is a data integrity and reliability issue.