jmsperu commented on code in PR #12898:
URL: https://github.com/apache/cloudstack/pull/12898#discussion_r4356700526
##########
scripts/vm/hypervisor/kvm/nasbackup.sh:
##########
@@ -176,6 +249,14 @@ backup_running_vm() {
exit 1
fi
+ # Throttle backup bandwidth if requested (MiB/s per disk)
+ if [[ -n "$BANDWIDTH" ]]; then
+ for disk in $(virsh -c qemu:///system domblklist $VM --details 2>/dev/null
| awk '/disk/{print$3}'); do
+ virsh -c qemu:///system blockjob $VM $disk --bandwidth "${BANDWIDTH}"
2>/dev/null || true
+ done
+ log -ne "Backup bandwidth limited to ${BANDWIDTH} MiB/s per disk for $VM"
Review Comment:
Tested on a lab host today, so here is the answer to point 2: libvirt does
accept `blockjob --bandwidth` against a push-mode backup job, and QEMU applies
it.
**Setup.** Ubuntu 24.04, libvirt 10.0.0, QEMU 8.2.2 (the versions on our
production KVM hosts). Guest `i-2-2-VM` with `vda` = 4 GiB sparse qcow2 root
(172 MiB allocated) and `vdb` = 2 GiB qcow2 filled from `/dev/urandom` so
nothing compresses or sparsifies. Backup target on the host's local disk. The
host is a VM, so the guest ran under TCG; that does not touch the block layer.
Each run below is a full push backup started with `virsh backup-begin
--backupxml`, exactly as the script does, polled every 2 s with `domjobinfo`
and `blockjob --info --bytes`.
| Run | What | Wall time | Rate |
|---|---|---|---|
| B1 | vdb, no limit | 4 s | 421 MiB/s |
| B2 | vdb, `virsh blockjob i-2-2-VM vdb --bandwidth 20` right after
`backup-begin` | 99 s | 20.6 MiB/s |
| B3 | vda + vdb, `--bandwidth 20` on each | 205 s | 20 MiB/s per disk, 40
MiB/s aggregate while both ran |
| B4 | stopped VM, `qemu-img convert -r 20M` (QEMU 8.2 has `-r`) | 102 s |
20.0 MiB/s (668 MiB/s without `-r`) |
What B2 looked like straight after the set-speed call (rc=0, empty stdout):
```
$ virsh blockjob i-2-2-VM vdb --info --bytes
Backup: [ 2.88 %] Bandwidth limit: 20971520 bytes/s (20.000 MiB/s)
$ virsh qemu-monitor-command i-2-2-VM '{"execute":"query-block-jobs"}'
"device": "backup-vdb-libvirt-1-format", "len": 2147483648, "offset":
87031808, "status": "running", "speed": 20971520, "type": "backup"
```
and the progress samples, 40 to 42 MiB per 2 s poll:
```
t+40s File processed: 872.000 MiB vdb: Backup: [42.67 %] Bandwidth limit:
20971520 bytes/s (20.000 MiB/s)
t+60s File processed: 1.252 GiB vdb: Backup: [62.59 %] Bandwidth limit:
20971520 bytes/s (20.000 MiB/s)
```
So on this libvirt the lookup resolves (the backup job registers a block job
per disk, `backup-<disk>-libvirt-<n>-format` at the QEMU level) and the limit
is enforced per disk, which is what the script's log line claims. The script's
error handling from the earlier fix still matters for older libvirt versions I
could not test here.
Two things worth knowing that the test showed, neither a bug in the change:
1. The limit is set a moment after `backup-begin`, so the first ~90 MiB of
B2 went at full speed before the set-speed call landed. On a fast array that is
a fraction of a second; it cannot be avoided because libvirt's backup XML has
no bandwidth attribute.
2. The limit counts virtual bytes, unallocated regions included: the 4 GiB
mostly empty `vda` in B3 still took 205 s at 20 MiB/s, even though the
resulting file was 172 MiB. Admins sizing `nas.backup.bandwidth.limit.mbps`
should expect running-VM backups to take `virtual size / limit`, not `allocated
size / limit`. I will add a sentence to the setting description so that is not
a surprise.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
