3.1: starting hvm from iso causes stacktrace

[qjoo]

qvm-start subgraph --cdrom=disp15:/home/user/Downloads/os.iso 
--> Loading the VM (type = HVM)...
Traceback (most recent call last):
  File "/usr/bin/qvm-start", line 131, in <module>
    main()
  File "/usr/bin/qvm-start", line 115, 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 326, in start
    return super(QubesHVm, self).start(*args, **kwargs)
  File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1901, 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 'subgraph'

[marmarek]

Check /var/log/libvirt/libxl/libxl-driver.log - I guess you'll find something about wrong path...
If it's not the case, check if your dispvm have xen-blkback kernel module loaded.

[marmarek]

Check /var/log/libvirt/libxl/libxl-driver.log - I guess you'll find something about wrong path...
If it's not the case, check if your dispvm have xen-blkback kernel module loaded.

[andrewdavidwong]

I'm assuming this issue has been resolved based on the lack of recent activity. If not, please feel free to re-open it.

[andrewdavidwong]

I'm assuming this issue has been resolved based on the lack of recent activity. If not, please feel free to re-open it.