qvm-block: Attaching dom0 files to VMs may fail in R3

[3hhh]

Calling

qvm-block -A [VM_A] dom0:/var/lib/qubes/appvms/[VM_B]/private.img
Traceback (most recent call last):
File "/usr/bin/qvm-block", line 151, in
main()
File "/usr/bin/qvm-block", line 105, in main
block_attach(qvm_collection, vm, dev, **kwargs)
File "/usr/lib64/python2.7/site-packages/qubes/qubesutils.py", line 408,
in block_attach
block_detach(attached_vm['vm'], attached_vm['frontend'])
File "/usr/lib64/python2.7/site-packages/qubes/qubesutils.py", line 446,
in block_detach
vm.libvirt_domain.detachDevice(etree.tostring(disk, encoding='utf-8'))
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1095, in
detachDevice
if ret == -1: raise libvirtError ('virDomainDetachDevice() failed',
dom=self)
libvirt.libvirtError: Requested operation is not valid: Domain is not
running

will result in the error above, if VM_A is running, but VM_B is not. In R2
it worked. In R3 it only works, if both VM_A and VM_B are running - which is
kind of strange as that ensures that the same file is attached to two VMs.

[3hhh]

Funny thing:

If you create a symlink to /var/lib/qubes/appvms/[VM_B]/private.img in your home directory and use that one instead of the direct path, it will work. If you do the same in /tmp, it won't work (different error then though). This is a strange one.

[3hhh]

Funny thing:

If you create a symlink to /var/lib/qubes/appvms/[VM_B]/private.img in your home directory and use that one instead of the direct path, it will work. If you do the same in /tmp, it won't work (different error then though). This is a strange one.

[marmarek]

Fixed here: QubesOS/qubes-core-admin@310ba9f

[marmarek]

Fixed here: QubesOS/qubes-core-admin@310ba9f