Re: unable to start a nested vm due to iommu_group issue

[daggs via Users]

> Sent: Friday, June 21, 2024 at 12:15 PM
> From: "daggs via Users" 
> To: users@lists.libvirt.org
> Subject: unable to start a nested vm due to iommu_group issue
>
> Greetings,
>
> I'm working on a new os for my server which runs 2 vms. I'm using nested vms 
> to work on it so I won't take down the server.
> the new os is alpine 3.20, qemu is 9.0.1, libvirt is 10.3.0.
>
> I have a device I want to pass to one of the guests, here is the iommu group 
> layout:
> IOMMU Group 18 00:1f.0 ISA bridge [0601]: Intel Corporation 82801IB (ICH9) 
> LPC Interface Controller [8086:2918] (rev 02)
> IOMMU Group 18 00:1f.2 SATA controller [0106]: Intel Corporation 
> 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] [8086:2922] 
> (rev 02)
> IOMMU Group 18 00:1f.3 SMBus [0c05]: Intel Corporation 82801I (ICH9 Family) 
> SMBus Controller [8086:2930] (rev 02)
> IOMMU Group 18 00:1f.4 Audio device [0403]: Intel Corporation 82801I (ICH9 
> Family) HD Audio Controller [8086:293e] (rev 03)
>
> the device in question is 00:1f.4:
> utils-server:/home/igor# lspci -s 00:1f.4 -nnv
> 00:1f.4 Audio device [0403]: Intel Corporation 82801I (ICH9 Family) HD Audio 
> Controller [8086:293e] (rev 03)
> Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
> Flags: bus master, fast devsel, latency 0, IRQ 10, IOMMU group 18
> Memory at e108 (32-bit, non-prefetchable) [size=16K]
> Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit+
> Kernel driver in use: vfio-pci
>
> to achieve that, I've compiled the kernel with acs patch and defined it in 
> the kernel cmdline:
> BOOT_IMAGE=/boot/vmlinuz-lts root=UUID=44299ace-27c6-4047-8cbd-bbffcc0a65f0 
> ro modules=sd-mod,usb-storage,ext4 quiet rootfstype=ext4 iommu=pt 
> intel_iommu=on pcie_acs_override=id:8086:293e,8086:10c9
>
> I see in dmesg, acs is enabled, see:
> # dmesg | grep "ACS overrides"
> [0.00] Warning: PCIe ACS overrides enabled; This may allow non-IOMMU 
> protected peer-to-peer DMA
>
> the xml file can be found at https://bpa.st/FARQ.
> when I try to start the vm, I get this:
> # virsh start streamer
> error: Failed to start domain 'streamer'
> error: internal error: QEMU unexpectedly closed the monitor (vm='streamer'): 
> 2024-06-21T08:39:17.959476Z qemu-system-x86_64: -device 
> {"driver":"vfio-pci","host":":00:1f.4","id":"hostdev0","bus":"pcie.0","addr":"0x1f.0x5"}:
>  vfio :00:1f.4: group 18 is not viable
> Please ensure all devices within the iommu_group are bound to their vfio bus 
> driver
>
> any ideas what am I missing? is it possible this cannot work within a vm?
>
> Thanks,
>
> Dagg
>

answering to myself, I needed to unbind all the devices in the same iommu group.

hope it helps anyone else

Re: Running libvirt without dnsmasq

[proc...@riseup.net]

On 6/19/24 18:30, Daniel P. Berrangé wrote:

On Wed, Jun 19, 2024 at 06:21:29PM -, proc...@riseup.net wrote:

Hi, we are trying to document a way for our users to run libvirt without
dnsmasq to reduce attack surface on the host. We are aware that the
default network uses it but plan to disable that and use our own custom
configured networks instead. Uninstalling dnsmasq causes libvirt to
refuse to start even if the default network is no longer running.
Is this possible or is this something that needs code changes upstream?


The virtual network driver validates existance of dnsmasq at startup,
but nothing requires you to actually run the virtual network driver,
if you're intending to do your own thing with network setup.

It sounds like you're using the old monolithic 'libvirtd' daemon. We
always build libvirt with modules support, so all drivers are dlopen'd
on startup.



How to check that?


Thus if you're not intending to use the libvirt virtual network feature,
simply don't install its modyle, and then libvirtd will see the module
doesn't exist, and skip the dlopen.



That sounds like something people would do who compile from source code?

We're using libvirtd (9.0.0-4) from Debian package sources. [1]


If you're using the new modular daemons, then even if installed, the
virtnetworkd daemon won't get launched unless some guest is configured
to use it. So if you're intending to setup network bridges yourself,
virtnetworkd shouldn't run.


That is libvirtd 9.x or 10.x?

Is there a chance that something is wrong with the libvirtd compilation 
settings by Debian's packaging?


[1] packages.debian.org/bookworm/libvirt-daemon