Internal error: libxenlight

Anybody having an error message when trying to boot a StandaloneVM? Getting this error message
returned:

“internal error: libxenlight”

Look for errors in /var/log/libvirt/libxl/libxl-driver.log in dom0.

I’m seeing quite a few entries like this:

libxl_pci.c:396:sysfs_write_bdf: Couldn’t open /sys/bus/pci/drivers/pciback/allow_interrupt_control: No such file or directory

Are there any other errors? Can you provide some more log? Run this in dom0 terminal:
sudo tail -fn0 /var/log/libvirt/libxl/libxl-driver.log
Then start your StandaloneVM and copy all the output from dom0 terminal.

Here is the output:

libxl: libxl_nic.c:487:libxl__device_nic_set_devids: Domain 73:Unable to set nic defaults for nic 0

Not sure what to make of it.
Do you have PCI devices passthrough to this StandaloneVM?

It’s using PVH mode, which according to the fine print, doesn’t allow for PCI passthrough.

The other error message is:

“libxenlight failed to create new domain”

How did you create this StandaloneVM? Is it based on existing template or not based on template and you’ve installed the system from ISO?

It is an existing template yes.

Do you have the same error for any new StandaloneVM? Or just this specific StandaloneVM? What template did you use for it?

It just seems to be the mirage-firewall template causing this result. The fedora-37-dvm uses the vanilla fedora-37 template. The mirage-firewall template appears to be the culprit, but the source of the issue is as of yet unknown.

I’m not familiar with mirage-firewall so I don’t have any advice. But it’d be better to rename the topic to indicate that this problem is related to mirage-firewall so someone who is familiar with it will see it.

There are also some other errors in /var/log/qubes/guid.mirage-firewall.log and
/var/log/qubes/qrexec.mirage-firewall.log

Failed to reconnect to qrexec-agent terminating

Failed to connect to gui-agent

I think this error has to do with the vm-interface API:

Qubes VM have some settings set by dom0 based on VM settings. There are multiple configuration channels, which includes:

QubesDB
XenStore (in Qubes 2, data the same as in QubesDB, keys without leading /)
Qubes RPC (called at VM startup, or when configuration changed)
GUI protocol

I’m seeing some errors relating to qubes.WindowIconUpdaterUpdater; which is found as a function in the
following docs:

https://qubes-doc-rst.readthedocs.io/en/latest/developer/debugging/vm-interface.html#gui-protocol
https://qubes-doc-rst.readthedocs.io/en/latest/developer/debugging/vm-interface.html#qubes-rpc
https://qubes-doc-rst.readthedocs.io/en/latest/developer/debugging/vm-interface.html#qubesdb

I wonder if the issue is somehow related to the other error message with the generation of a kernel seed
to be added to the kernel entropy pool. I think it might be related to how a random seed is generated and VMs are assigned a unique ID from this pool.

Hi, can you describe how you created the mirage template? If it’s via qubes-builder you will have to set the kernel of the AppVM using this template to pvgrub2-pvh (you may have to install it via qubes-update).

And as a side note, using mirage-fw as a template is still in experimental status and you might have unexpected issues during installation/upgrade. I mean, once installed it will works as with the recommended installation procedure, but it’s actually more difficult to update. That’s why it’s still not the recommended installation procedure.

Why is this change necessary; up until recently, the template has had no issues. How is the change to the
pvgrub2-pvh made?

Install grub2-xen-pvh in dom0, then change your VM kernel to pvgrub2-pvh in Qube settings and change mode to PVH if it was HVM.