[Archlinux] Not possible to pass iso image to qvm-start

[tezeb]

Qubes OS version (e.g., R3.2):

R3.2

Affected TemplateVMs (e.g., fedora-23, if applicable):

N/A

---

Expected behavior:

Running:
qvm-start customHVM --hddisk=downloadVM:/tmp/arch.iso

shall start customHVM with downloadVM attached as hd.

Actual behavior:

It throws exception:

--> Loading the VM (type = HVM)...
Traceback (most recent call last):
  File "/usr/bin/qvm-start", line 136, in <module>
    main()
  File "/usr/bin/qvm-start", line 120, in main
    xid = vm.start(verbose=options.verbose, preparing_dvm=options.preparing_dvm, start_guid=not options.noguid, notify_function=tray_notify_generic if options.tray else None)
  File "/usr/lib64/python2.7/site-packages/qubes/modules/01QubesHVm.py", line 335, in start
    return super(QubesHVm, self).start(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1966, in start
    self.libvirt_domain.createWithFlags(libvirt.VIR_DOMAIN_START_PAUSED)
  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1059, in createWithFlags
    if ret == -1: raise libvirtError ('virDomainCreateWithFlags() failed', dom=self)
libvirt.libvirtError: internal error: libxenlight failed to create new domain 'customHVM'

Steps to reproduce the behavior:

Run above command.

General notes:

It works fine(tries to boot from empty drive) when there is no --hddisk param.

[marmarek]

Check /var/log/libvirt/libxl/libxl-driver.log for details.
Also check if you have xen-blkback module loaded in downloadVM. Have you checked --cdrom option instead?

[marmarek]

Check /var/log/libvirt/libxl/libxl-driver.log for details.
Also check if you have xen-blkback module loaded in downloadVM. Have you checked --cdrom option instead?

[tezeb]

It works with Debian template, so I guess it is Archlinux specific.
xen_blkback is loaded and the issue happens regardless of using --cdrom or --hddisk.

Logs from the libxl-driver.log:

2017-05-03 21:51:32 CEST libxl: error: libxl_dm.c:1689:stubdom_xswait_cb: Stubdom 85 for 84 startup: startup timed out
2017-05-03 21:51:32 CEST libxl: error: libxl_create.c:1342:domcreate_devmodel_started: device model did not start: -9
2017-05-03 21:51:32 CEST libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block remove [32690] exited with error status 1
2017-05-03 21:51:32 CEST libxl: error: libxl_device.c:1138:device_hotplug_child_death_cb: script: /etc/xen/scripts/block failed; error detected.
2017-05-03 21:51:32 CEST libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block remove [32708] exited with error status 1
2017-05-03 21:51:32 CEST libxl: error: libxl_device.c:1138:device_hotplug_child_death_cb: script: /etc/xen/scripts/block failed; error detected.
2017-05-03 21:51:42 CEST libxl: error: libxl_device.c:1177:device_destroy_be_watch_cb: timed out while waiting for /local/domain/52/backend/vbd/85/51760 to be removed
2017-05-03 21:51:42 CEST libxl: error: libxl.c:1699:devices_destroy_cb: libxl__devices_destroy failed for 85
2017-05-03 21:51:42 CEST libxl: error: libxl_device.c:1177:device_destroy_be_watch_cb: timed out while waiting for /local/domain/52/backend/vbd/84/51760 to be removed
2017-05-03 21:51:42 CEST libxl: error: libxl.c:1699:devices_destroy_cb: libxl__devices_destroy failed for 84

[tezeb]

It works with Debian template, so I guess it is Archlinux specific.
xen_blkback is loaded and the issue happens regardless of using --cdrom or --hddisk.

Logs from the libxl-driver.log:

2017-05-03 21:51:32 CEST libxl: error: libxl_dm.c:1689:stubdom_xswait_cb: Stubdom 85 for 84 startup: startup timed out
2017-05-03 21:51:32 CEST libxl: error: libxl_create.c:1342:domcreate_devmodel_started: device model did not start: -9
2017-05-03 21:51:32 CEST libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block remove [32690] exited with error status 1
2017-05-03 21:51:32 CEST libxl: error: libxl_device.c:1138:device_hotplug_child_death_cb: script: /etc/xen/scripts/block failed; error detected.
2017-05-03 21:51:32 CEST libxl: error: libxl_exec.c:118:libxl_report_child_exitstatus: /etc/xen/scripts/block remove [32708] exited with error status 1
2017-05-03 21:51:32 CEST libxl: error: libxl_device.c:1138:device_hotplug_child_death_cb: script: /etc/xen/scripts/block failed; error detected.
2017-05-03 21:51:42 CEST libxl: error: libxl_device.c:1177:device_destroy_be_watch_cb: timed out while waiting for /local/domain/52/backend/vbd/85/51760 to be removed
2017-05-03 21:51:42 CEST libxl: error: libxl.c:1699:devices_destroy_cb: libxl__devices_destroy failed for 85
2017-05-03 21:51:42 CEST libxl: error: libxl_device.c:1177:device_destroy_be_watch_cb: timed out while waiting for /local/domain/52/backend/vbd/84/51760 to be removed
2017-05-03 21:51:42 CEST libxl: error: libxl.c:1699:devices_destroy_cb: libxl__devices_destroy failed for 84

[marmarek]

If that's something Archlinux specific, it's probably about /etc/xen/scripts/block, or xendriverdomain.service. Can you check the later if its running (systemctl status xendriverdomain.service)?

[marmarek]

If that's something Archlinux specific, it's probably about /etc/xen/scripts/block, or xendriverdomain.service. Can you check the later if its running (systemctl status xendriverdomain.service)?

[tezeb]

Bingo! The daemon was inactive.
Running systemctl start xendriverdomain fixed the issue.

I will check if this needs patching in up to date Archlinux template(mine is few months old) and push fix if necessary.

[tezeb]

Bingo! The daemon was inactive.
Running systemctl start xendriverdomain fixed the issue.

I will check if this needs patching in up to date Archlinux template(mine is few months old) and push fix if necessary.

[marmarek]

Does it still happen?

[marmarek]

Does it still happen?

[tezeb]

No. It works fine now.
Thanks

[tezeb]

No. It works fine now.
Thanks