GitHub user herrickP added a comment to the discussion: Problem with volume resize after upgrade from 4.22.0 to 4.22.1
This looks like a libvirt/QEMU live-resize issue rather than a Linstor/ACS problem. When the volume is resized via ACS, it issues a virsh blockresize (or updates the disk via Linstor's DRBD/LVM layer), but if the VM's underlying device mapping or DRBD metadata wasn't refreshed properly post-upgrade, libvirt's cached domblkinfo will keep reporting the old capacity until a fresh dumpxml/device re-attach happens, which only occurs on a full stop/start (since reboot alone doesn't re-read block device geometry). A few things to check before filing a bug: Compare virsh dumpxml source dev paths for an affected VM vs. a newly created one, you mentioned seeing differences there, which suggests the older domains may still be referencing a stale Linstor resource path/minor number from before the upgrade. Check if blockresize was actually invoked on the live domain (libvirt logs) or if ACS only resized the Linstor resource and assumed libvirt would pick it up. This smells like a regression introduced in how 4.22.1 handles live volume resize for KVM+Linstor combos specifically, worth checking the changelog/diff between 4.21 and 4.22.1 around the LibvirtResizeVolumeCommand handling. For now, the stop/start workaround seems to be the only reliable fix until this is patched. If you haven't already, definitely open a GitHub issue with your dumpxml diffs, that'll help maintainers spot exactly where the stale reference is held. Side note - I run a decent chunk of CloudStack on Accuweb.cloud KVM+Linstor in production and haven't hit this yet, but we're still on 4.21.x for exactly this kind of reason, newer ACS minor releases sometimes need a cycle to shake out edge cases like this. Might be worth holding off upgrading further nodes until this is confirmed/fixed. GitHub link: https://github.com/apache/cloudstack/discussions/13494#discussioncomment-17485603 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
