This was indeed caused by libvirt starting to use -blockdev. The issue is that qemu's 'auto-read-only' property which is used by libvirt for the backing files doesn't properly work if the 'host_device' backend encounters a read-only LV.
The above situation also happens if you have an read-only LV in the backing chain. In the current upstream situation of qemu's APIs there currently isn't anything that libvirt can do in this case, because any solution would either not fix the problem completely or would require sacrificing other features, the auto-read-only property needs to be fixed in qemu. I've also filed https://bugzilla.redhat.com/show_bug.cgi?id=1828252 to track this issue. ** Bug watch added: Red Hat Bugzilla #1828252 https://bugzilla.redhat.com/show_bug.cgi?id=1828252 -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1875139 Title: Domain fails to start when 'readonly' device not writable Status in QEMU: New Bug description: This issue is introduced in QEMU 4.2.0 (4.1.0 is working fine) My root disk is a LVM2 volume thin snapshot that is marked as read-only But when I try to start the domain (using virt-manager) I get the following error: Error starting domain: internal error: process exited while connecting to monitor: 2020-04-26T06:55:06.342700Z qemu-system-x86_64: -blockdev {"driver":"host_device","filename":"/dev/vg/vmroot-20200425","aio":"native ","node-name":"libvirt-3-storage","cache":{"direct":true,"no- flush":false},"auto-read-only":true,"discard":"unmap"} The device is not writable: Permission denied Changing the lvm snapshot to writeable allows me to start the domain. (Making it changes possible during domain is running) I don't think QEMU should fail when it can't open a (block) device when the read-only option is set. (why is write access needed?) Reproduce steps: * Create LVM read-only volume (I don't think any data is needed) * Create domain with read-only volume as block device * Try to start the domain To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1875139/+subscriptions