"failed to prepare PCI device 07:00.0" error when trying to start netvm

[Eric Smith]

Yeah, I am wondering what this means.  I can start appvms but can't start any that depend on netvm. 
Then, to get more info, I tried a qubes-dom0-update in Konsole.  This time, it told me that:
"/usr/lib/qubes/unbind-pci-device.sh:  line 47: echo: write error: No such device"
So I looked at the code and appearent it didn't like what was in the $BIND variable and appearently
could not find the driver whose name was stored in the $BIND variable appearently.
This problem started after I had to turn off the computer manually because it froze. 
I rebooted about 4 times but the problem persists.  I can start the usbvm because it's a Standalone
vm and does not depend on netvm, but not the others.  I wonder how I could fix this.
     

[Eric Smith]

I tried a live linux distro on a dvd to ensure that the networking hardware is working properly on the computer.
When I look under the 'Devices' tab of netvm, not surprisingly, no device is listed with the 07:00 address.
Okay, that gave me an idea.  I am going to look at the 'Devices' tabs of the remaining appvms if, by chance, some other
appvm is using that device at the 07:00 address.  But then, after reboot, only the dom0 is started and none of the other vms start,
because they all depend on netvm.  So, is it possible that something is grabbing the device at 07:00 so it is not available to any of the vms?

[Marek Marczykowski-Górecki]

On Sun, Dec 07, 2014 at 02:29:16AM -0800, Eric Smith wrote:
> I tried a live linux distro on a dvd to ensure that the networking hardware
> is working properly on the computer.

> When I look under the *'Devices'* tab of *netvm, *not surprisingly, no

> device is listed with the 07:00 address.
> Okay, that gave me an idea. I am going to look at the 'Devices' tabs of
> the remaining appvms if, by chance, some other
> appvm is using that device at the 07:00 address. But then, after reboot,
> only the dom0 is started and none of the other vms start,
> because they all depend on netvm. So, is it possible that something is
> grabbing the device at 07:00 so it is not available to any of the vms?

It looks like 07:00 do not exists in your system. Check qvm-pci cmdline
tool and remove that device from netvm.

If looks you've found a bug in Qubes Manager - devices tab lists only
existing devices, not all assigned to the Vm.

--
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[Eric Smith]

I think what caused this problem was that I unchecked the box ¨Enable Wireless" on network manager icon.  I use ethernet most of the time anyway.  At the same time I had an ssh tunneling session happening in the netvm terminal. 
the address 07:00 is for the wireless card.  Since I unchecked the box, the 07:00 address was no longer relevant.  Unchecking the box should not have caused the system to become unstable.  That maybe a bug.
Anyhow, now the computer is working, I started it up today.  But the "Enable Wireless" check box is missing.  So, unchecking that check box caused the entire wireless menu to disappear from the network manager icon!  Anyway to get it back?
Also the 07:00 is back on the Devices list in the netvm.  I think I remove it and make this netvm only ethernet and create another netvm for wireless only.  Thank you.

[Marcus at WetwareLabs]

Hello,

I can confirm that this bug with VM Manager is still lurking somewhere. I've been using Qubes 3.1 for few days now and suddenly after booting the sys-net won't start (Error starting VM 'sys-net': PCI device 08:00.0 does not exist (domain sys-net)).  Funny thing, I even don't have a PCI device with that address..  

In Qubes VM Manager in Devices tab theres 00:19.0 (Intel network adapter) attached, but no 08:00.0. But when listing attached devices with

qvm-pci -l sys-net

it shows

['00:19.0' , '08:00.0']

Then

qvm-pci -d sys-net 08:00.0

resolves the situation.

So at least theres still the bug that VM Manager does not list attached (but non-existing) devices, and that is now preventing from starting VMs

I don't know what caused this. Only thing that can come to mind is that I've tried the PCI passthrough reset relaxation for USB VM (explained here https://www.qubes-os.org/doc/assigning-devices/ ), but that would not work, so I looked at the Xen pages and their example lists command
echo 0000:08:00.0 > /sys/bus/pci/drivers/pciback/permissive
instead of 

echo 0000:04:00.0 > /sys/bus/pci/drivers/pciback/permissive

So I modified the qubes-pre-netvm.service accordingly.

At first I thought these were some kind of general configuration flags for setting permissive mode, but then I realised these are actually just example PCI addresses and have to be changed to reflect the address of the actual USB controller! :) However at this point I've already tried setting the pci_strictreset false with qvm-prefs and that worked, so I forgot about the pre-netvm service until this happened. Interestingly, just disabling the problem causing service would not be enough to resolve the situation, but I had to use qvm-pci manually (only once) to remove the attachment. So somehow these settings survive the restart..?