Qvm-block attach vmname source:loopdevice_for_iso -o devtype=cdrom

Is this currently supported in R4.0?

That is, not a real cdrom device, but an ISO mounted as a loop device?

I can attach/detach standard block devices all day long without “-o devtype=cdrom”

But with “-o devtype=cdrom” I get

Got empty response from qubesd. See journalctl in dom0 for details.

journalctl says:

Oct 29 17:22:24 dom0 qubesd[3154]: unhandled exception while calling src=b’dom0’ meth=b’admin.vm.device.block.Attach’ dest=b’VMNAME_EXCISED’ arg=b’dom0+loop2’ len(untrusted_paylo
Oct 29 17:22:24 dom0 qubesd[3154]: Traceback (most recent call last):
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib/python3.5/site-packages/qubes/api/init.py”, line 275, in respond
Oct 29 17:22:24 dom0 qubesd[3154]: untrusted_payload=untrusted_payload)
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib64/python3.5/asyncio/futures.py”, line 381, in iter
Oct 29 17:22:24 dom0 qubesd[3154]: yield self # This tells Task to wait for completion.
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib64/python3.5/asyncio/tasks.py”, line 310, in _wakeup
Oct 29 17:22:24 dom0 qubesd[3154]: future.result()
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib64/python3.5/asyncio/futures.py”, line 294, in result
Oct 29 17:22:24 dom0 qubesd[3154]: raise self._exception
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib64/python3.5/asyncio/tasks.py”, line 240, in _step
Oct 29 17:22:24 dom0 qubesd[3154]: result = coro.send(None)
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib/python3.5/site-packages/qubes/api/admin.py”, line 1276, in vm_device_attach
Oct 29 17:22:24 dom0 qubesd[3154]: yield from self.dest.devices[devclass].attach(assignment)
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib/python3.5/site-packages/qubes/devices.py”, line 254, in attach
Oct 29 17:22:24 dom0 qubesd[3154]: device=device, options=device_assignment.options)
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib/python3.5/site-packages/qubes/events.py”, line 231, in fire_event_async
Oct 29 17:22:24 dom0 qubesd[3154]: kwargs, pre_event=pre_event)
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib/python3.5/site-packages/qubes/events.py”, line 166, in _fire_event
Oct 29 17:22:24 dom0 qubesd[3154]: effect = func(self, event, **kwargs)
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib/python3.5/site-packages/qubes/ext/block.py”, line 276, in on_device_pre_attached_block
Oct 29 17:22:24 dom0 qubesd[3154]: device=device, vm=vm, options=options))
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib/python3.5/site-packages/qubes/app.py”, line 101, in wrapper
Oct 29 17:22:24 dom0 qubesd[3154]: return attr(*args, **kwargs)
Oct 29 17:22:24 dom0 qubesd[3154]: File “/usr/lib64/python3.5/site-packages/libvirt.py”, line 563, in attachDevice
Oct 29 17:22:24 dom0 qubesd[3154]: if ret == -1: raise libvirtError (‘virDomainAttachDevice() failed’, dom=self)
Oct 29 17:22:24 dom0 qubesd[3154]: libvirt.libvirtError: internal error: No device with bus ‘xen’ and target ‘xvdi’

Also: if I just attach a loop device pointing at an iso file as a normal disk block device it is attached to the target but it not recognized as a cdrom.

B

Bumping this question, any ideas if the -o option devtype=cdrom (e.g.

qvm-block attach vnname sourcevm:loopdevice_for_iso -o devtype=cdrom

)
is supported for attaching ISOs to running VMs as CDROM devices?

[After two semi-recent qubes-issues I created were closed rightly because I had not done my due diligence, I am trying to approach these unknowns in the correct manner, by posting to the forum and/or list.]

B