ghost82

Try to add to syslinux config: video=efifb:off Add also this: modprobe.blacklist=i2c_i801,i2c_smbus Try to pass one of these attached vbios. i915ovmf.rom i915ovmf-simple.rom

It could be an issue with your provider. Is your public ip address static? What is the public ip you read in the router gui? And what is the ip you read from a terminal window: curl ifconfig.me I think cgnat is active for your connection..

The only thing I can see is that your audio at 00:1f.3 doesn't support reset. Since it is grouped with isa bridge, memory controller and smbus and since the smsbus has the i2c_i801 kernel module, I would try to add to the syslinux config this: modprobe.blacklist=i2c_i801,i2c_smbus Reboot the server, start the vm and see if it works. Note that when you reboot the vm only, without rebooting the whole server, audio may not work.

Attach diagnostics after trying to run the vm with gpu passthrough only.

That's new for me that an onboard audio is attached to usb.. I can see two possible issues here: 1. the cause could be the emulated usb controllers you are attaching the audio devices to: by passing vendor/product ids you are attaching that devices to an emulated controller, defined in the xml (UHCI/EHCI probably). These emulated controllers sometimes don't play well with some hardware. If you can, you should passthrough the whole usb controller as a pci device (the controller to which your audio is attached) and remove the vendor/product ids. 2. crappy audio drivers: check if you have installed the latest realtek alc4080 drivers.

Nice that you found the solution however: It could work, but bare metal hardware is multifunction, so it is strongly recommended to make the gpu a multifunction device in the vm too. If it's not multifunction, you could: 1. be unable to install drivers in the guest, because of crappy drivers, they could check for a multifunction device, and could fail the installation if they don't find it; have unexpected drivers behaviour too. 2. in some oses digital audio will not work correctly if the device is not set as multifunction, mac os for example. Q35 should be the default these days, for every os, because it has better support for pcie passthrough devices. UEFI is not linked to q35, you could have a vm booting in uefi both with q35 and i440fx; q35 and i440fx are only emulated chipsets, q35 being more recent. What is important for uefi is booting with a uefi capable bios (ovmf). This is not strictly necessary; it is necessary when the gpu you want to passthrough is flagged by the host os as "boot vga"; if it's flagged that way the host os will make a shadow copy of the vbios, but it's not a 1:1 copy of the gpu vbios, so when the vm will try to use it, it will fail; passing through a vbios file will fix it. This is true for linux hosts only, windows doesn't have this issue, in fact you are able to dump a 1:1 copy of the vbios on a bare metal windows machine even if the gpu is the boot gpu.

There's nothing useful in this log. Remove any boot order line in the xml. Boot into ovmf by pressing esc as soon as the vm starts.*** Boot into ovmf uefi shell (in the ovmf menu you should see something like boot from, or something similar, choose uefi internal shell). Check the map of your drives, you should see FSx listed. One of these FSx is the boot partition of the nvme drive. In the uefi shell type: FSx: cd EFI\Microsoft\Boot bootmgfw.efi press enter after each line FSx: x is a number, probably 0 Check if it boots that way. ***Do this only if you are not redirected directly to the uefi shell on boot.

As far as the vbios attachments, the edited rom is not edited from the original (there are a lot of differences if hex compared). Use a vbios dumped from your gpu and edit the header; the rom you will use must start with 0x55AA: if you don't remove the nvflash header the vbios will not work. Add video=efifb:off to your syslinux configuration. Configure the gpu in the xml as multifunction (search forum).

Delete this line: <boot dev='hd'/>

It's not unraid nor qemu fault, it's the device that is bugged. If you check the device capabilities you will find something like: Capabilities: [b0] MSI-X: Enable- Count=22 Masked- Vector table: BAR=0 offset=00002000 PBA: BAR=0 offset=00002100 In this example you have Count 22 and vector table with offset 0x2000; each vector table entry is 16 bytes, so 16x22 is 352 bytes; this means that it will extend to 0x2000+0x352 --> 0x2352 so the second offset is wrong. You can try to add an alias to the nvme pcie device in the xml and use qemu override custom argument: <qemu:override> <qemu:device alias='YOURALIASHERE'> <qemu:frontend> <qemu:property name='x-msix-relocation' type='string' value='bar2'/> </qemu:frontend> </qemu:device> </qemu:override> Didn't try with 6.11.x, in 6.10.x it was not possible because of bugs.

Iommu group 7 includes also an nvme drive, try to use pcie acs override "both" instead of only "downstream", to see if you can spit the ethernet card from the nvme drive. You should bind to vfio at boot the devices you want to passthrough.

Correct, the built-in vnc is available only with virtual vga, so if you passthrough a gpu the built-in option will not be there. You could add a virtual vga as primary display with novnc and the passed through gpu as secondary, but this defeats the purpose of passing through a gpu, better to use a vnc server/rdp solution inside the vm if you need remote access.

Maybe try to create a new vm with type q35 and point to the same disks; q35 has better support for pcie devices.

Bind to vfio audio and video of the gpu if you didn't. Check if in your syslog efifb is used for your gpu: if it is, add video=efifb:off to your syslinux configuration (you can check if efifb is stealing memory to vfio with command "cat /proc/iomem"). Check in the syslog if your gpu is marked as boot vga: if it is, dump your gpu vbios and use it (may need to remove the nvflash header from the vbios). Check the xml and set the target gpu as a multifunction device: check the forum, it was written several times about how to do it. Restart the server. Note that you can't use the same gpu at the same time for a vm and dockers.

that are not really files; the name without -partX is the whole disk, other names with -partX suffix are single partitions. You need to clone the whole disk, not sure if the command will works with the by-id for the source (it should work in my opinion), if it doesn't clone the disk just find the sdX name of that disk and follow that post you linked. Command dd is fine too to clone disks to img, if you search google you will find examples, just use path/to/vdisk.img as the target (most examples use /dev/sdX as a target, to clone and restore files on a physical disk, but img as target will be fine). Make sure the target disk have enough space, larger than the physical disk you are cloning. The advice to sparsify the image is good too, so the image size will be that of the sizes of all the files, and make sure to enable trim in the vm for the vdisk.

ok, this has no sense to me because I cannot see why an app should check if the software is running in an os which has virtualization capabilities or not: this has nothing to do if the software is running in a vm or not. Anyway, if you have the svm flag your vm has virtualization capabilities; if it doesn't work (which I expect) the software is checking for something else.

Yes this may happen, because you are running a vm, and that flag is needed for efficiency. Yes, because svm flag is passed from the real cpu since you are passing through the cpu and so if nested virtualization is enabled in the kernel parameters you can run nested vms. That is a non sense to me, sorry

It's not very clear to me what you want to do..if you want to play games that check if they run in a vm then you need to know what they check and operate accordingly. Sometimes adding: <feature policy='disable'name='hypervisor'/> is enough to bypass the check. Sometimes custom compilation of qemu is required because the original package has some hardcoded things that applications may check. I'm not understanding why you are talking about nested virtualization (run a vm in a vm). If in your vm you have svm in your cpu features that means only that nested virtualization should work (for intel it is vmx). Probably you are confusing vmm with vmx flag (for intel)?

vmx is intel, svm is equivalent for amd. You can't have the vmx flag for a passed amd cpu, as in real hardware.

I noticed that too long time ago in my windows 11 vm; I'm not sure if this is a windows bug or qemu or the interaction with the 2. However, this doesn't seem to affect network or any other functionality, at least for me.

Probably related to graphic accelaration. Consider that vnc graphic only doesn't enable it, you need gpu passthrough.

You need nested virtualization setup in the host and cpu passthrough for the guest (only intel). You can't emulate penryn.

Try this: <!-- WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE OVERWRITTEN AND LOST. Changes to this xml configuration should be made using: virsh edit 5efce766-c82d-4abb-1d51-e82f1f7c5e4f or other application using the libvirt API. --> <domain type='kvm'> <name>Home Assistant</name> <uuid>5efce766-c82d-4abb-1d51-e82f1f7c5e4f</uuid> <description>Linux VM</description> <metadata> <vmtemplate xmlns="unraid" name="Linux" icon="default.png" os="linux"/> </metadata> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='8'/> <vcpupin vcpu='1' cpuset='28'/> <vcpupin vcpu='2' cpuset='9'/> <vcpupin vcpu='3' cpuset='29'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-6.0'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/5efce766-c82d-4abb-1d51-e82f1f7c5e4f_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough' check='none' migratable='on'> <topology sockets='1' dies='1' cores='2' threads='2'/> <cache mode='passthrough'/> </cpu> <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/user/domains/HassOS/haos_ova-7.1.qcow2'/> <target dev='hdc' bus='sata'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x11'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller> <controller type='pci' index='3' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='3' port='0x12'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/> </controller> <controller type='pci' index='4' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='4' port='0x13'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='usb' index='0' model='qemu-xhci' ports='15'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:a7:e7:9e'/> <source bridge='br0'/> <model type='virtio-net'/> <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0' keymap='en-us'> <listen type='address' address='0.0.0.0'/> </graphics> <audio id='1' type='none'/> <video> <model type='qxl' ram='65536' vram='65536' vgamem='16384' heads='1' primary='yes'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x10d5'/> <product id='0x5000'/> </source> <address type='usb' bus='0' port='3'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x43' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x41' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </hostdev> <memballoon model='none'/> </devices> </domain> 1. Bind to vfio 41:00.0 (already done) 2. Replace the whole xml 3. Start the vm ---- First available target bus different than 0 is 04: 01 in use by br0 02 in use by virtio-serial 03 in use by passed through 43:00.0 pcie-root-port with index=4 already in the xml: target bus 04 needs pcie-root-port with index=4

yes, the 2 show, but for whatever reason 41:00.0 doesn't: https://forums.unraid.net/topic/129157-vfio-bind-of-pcie-device/

If you have issues just post the vm xml or better the full diagnostics.