We have all been there. You need to pull a drive out of a running VM for maintenance, you issue the detach command, and libvirt just sits there staring at you. Then it finally gives up with an opaque error about the device being busy or locked. Most people just reboot the VM to force the release, but that is a sledgehammer approach that will earn you a grumpy ticket from the application team.

Why the kernel is holding onto your device

Usually, this isn’t libvirt being stubborn. It is the guest kernel holding a handle on the block device because of an active process or mount point that you forgot to clean up. If your application or a stray cron job is reading from the disk, the kernel won’t let go of the descriptor. Even if you think you unmounted the filesystem, check if anything is lurking in the background.

virsh domblklist vm_name --inactive; lsof +fG /dev/mapper/your_disk_device

• Verify if any processes have open file descriptors on the device mapper path
• Check /proc/mounts inside the guest to ensure no hidden bind mounts are active
• Use virsh qemu-monitor-command to force a block-job-cancel if a migration or backup left a ghost block job behind

If lsof returns nothing but the detach still fails, check for ghost block jobs. Sometimes a previous snapshot operation or a failed drive-mirror command leaves a block-job active in QEMU memory. You can manually query the monitor to see if there is a lingering job preventing the detach command from completing.

Before you try rebooting, dive into the QEMU monitor directly. It is the only way to see what the management layer is actually hiding from you. If you get into the habit of checking these locks first, you’ll save yourself an embarrassing maintenance window.