2

Short version:

Using systemctl start libvirtd (or libvirtd.service, seems to have the same effect?) crashes the system, without warning, if one of the pools has /dev allocated.

Long version:

I'm trying install a guest OS with the help of passthrough, on Archlinux, with virt-manager. I'm following this guide. In the Configuring Virtual Machine section, the first step is to add storage, and select the /dev. Once I do that, the system will reboot instantly, without any warning, after ~1 min. I have checked with systemctl status libvirtd at regular intervals, and the lowest time I got to see was 55 sec; I never got to see 1 min. The setting is saved in /etc/libvirt/storage/pool*.xml (pool-1.xml, or something like that). I deleted it in the meantime and now there are no more crashes. There are one and two threads on reddit, but none has any workaround.

Is this a known behaviour, or is it a quirk? How do I get around it and finish installing the guest OS?

  • 1
    What bothers me most is that it resets the system. I would understand if the service would crash, that the programs relying on it might crash (such as `virt-manager`), but why does it hard-reset the computer? – a concerned citizen Dec 13 '21 at 16:03
  • What devices did you pass through? What storage devices did you specify? – Marcus Müller Dec 13 '21 at 18:21
  • You're allowing your guest OS to access hardware that has hardware DMA access, and access to the PCIe bus itself, on a system that might have an imperfect IOMMU implementation and with sometimes really strangely behaving PCIe devices. There's very many ways this can go wrong! – Marcus Müller Dec 13 '21 at 18:23
  • @MarcusMüller I have a 3700x + B450 Tomahawk Max, using 5700xt (guest) + 750Ti (host) (and 32 GB RAM), and I'm following [this guide](https://dividebyzer0.gitlab.io/GPUpassthrough.html) (very similar setup). I doubt it's a matter of mismatch or imperfections (though since I'm not the manufacturer, I can't exclude them, either). It all happens when I reach the 1st step in the "Configuring Virtual Machine" section. – a concerned citizen Dec 13 '21 at 18:37
  • it definitely is the reason. If starting a VM resets the host, then a device you allowed your VM to control leads to a hardware reset. – Marcus Müller Dec 13 '21 at 18:39
  • @MarcusMüller Yes, but if I delete the setting holding the `/dev` pool, nothing happens, it works normally (as it does without that setting). So I would say it's something related to the `/dev` that `libvirtd` doesn't like. At any rate, I just received an advice to avoid passing `/dev` or `/dev/sdXX` and use the `qcow2` file format. – a concerned citizen Dec 13 '21 at 18:43
  • I don't understand what a "`/dev` pool" is? – Marcus Müller Dec 13 '21 at 18:46
  • Ah I see your guide is a bit strange, OK: You don't add a "dir" storage pool to give a VM direct access to a device file... That is *very* backwards. You select "create new storage pool", and there the type `Disk: Physical Disk Device` – Marcus Müller Dec 13 '21 at 18:48
  • @MarcusMüller I found the answer, added it below. It's been quite the bumpy ride, this. I wonder what will be next? – a concerned citizen Dec 13 '21 at 22:17

1 Answers1

4

It turns out I misunderstood the guide. In there, it says to select /dev/sdb (which is what I have), not /dev/sdb2 (which is what I thought, I only wanted that partition). There's a similar problem here (on askubuntu, and I also posted this here, on level1techs). Once I do that, it works (as backwards as it may be), and I can also add external partitions to be seen from within the guest OS.

Even so, I'd say it's a problem if it resets the system. The service should crash, go bananas, start knitting, drag other denendent programs after it, but not crash the system.