sub6 Posted March 28, 2020 Share Posted March 28, 2020 (edited) Hi, I think it started when I updated to 6.9.0-beta1. I also tried to downgrade to 6.8 but the problem stayed. I searched the forum, but found nothing similar. Once I create a VM I can start this Windows 10 VM without problems. The second time it kind of starts I don't see the windows startup circle and one assigned core rises to 100 % and nothing happens. When I recreate the VM with the same settings it starts without problems. I use a dedicated SSD for the VM and a Nvidia GPU is passed through. This is the Log after starting the VM. I can post the config if needed. Thank you for your help. -Sub6 SOLVED: By doing a fresh install of Unraid and transferring the config. ErrorWarningSystemArrayLogin -uuid a5c63b98-448a-ff23-9aa5-531b06e402c7 \ -display none \ -no-user-config \ -nodefaults \ -chardev socket,id=charmonitor,fd=34,server,nowait \ -mon chardev=charmonitor,id=monitor,mode=control \ -rtc base=localtime \ -no-hpet \ -no-shutdown \ -boot strict=on \ -device ich9-usb-ehci1,id=usb,bus=pci.0,addr=0x7.0x7 \ -device ich9-usb-uhci1,masterbus=usb.0,firstport=0,bus=pci.0,multifunction=on,addr=0x7 \ -device ich9-usb-uhci2,masterbus=usb.0,firstport=2,bus=pci.0,addr=0x7.0x1 \ -device ich9-usb-uhci3,masterbus=usb.0,firstport=4,bus=pci.0,addr=0x7.0x2 \ -device ahci,id=sata0,bus=pci.0,addr=0x3 \ -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 \ -blockdev '{"driver":"host_device","filename":"/dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSADB30857W","node-name":"libvirt-2-storage","cache":{"direct":false,"no-flush":false},"auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-2-format","read-only":false,"cache":{"direct":false,"no-flush":false},"driver":"raw","file":"libvirt-2-storage"}' \ -device ide-hd,bus=sata0.2,drive=libvirt-2-format,id=sata0-0-2,bootindex=1,write-cache=on \ -blockdev '{"driver":"file","filename":"/mnt/user/isos/virtio-win-0.1.173-2.iso","node-name":"libvirt-1-storage","auto-read-only":true,"discard":"unmap"}' \ -blockdev '{"node-name":"libvirt-1-format","read-only":true,"driver":"raw","file":"libvirt-1-storage"}' \ -device ide-cd,bus=ide.0,unit=1,drive=libvirt-1-format,id=ide0-0-1 \ -netdev tap,fd=36,id=hostnet0,vhost=on,vhostfd=37 \ -device virtio-net-pci,netdev=hostnet0,id=net0,mac=52:54:00:3c:2f:3f,bus=pci.0,addr=0x2 \ -chardev pty,id=charserial0 \ -device isa-serial,chardev=charserial0,id=serial0 \ -chardev socket,id=charchannel0,fd=38,server,nowait \ -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 \ -device vfio-pci,host=0000:26:00.0,id=hostdev0,bus=pci.0,addr=0x5,romfile=/mnt/user/isos/AsusStrix_GTX970.rom \ -device vfio-pci,host=0000:26:00.1,id=hostdev1,bus=pci.0,addr=0x6 \ -device vfio-pci,host=0000:03:00.0,id=hostdev2,bus=pci.0,addr=0x8 \ -sandbox on,obsolete=deny,elevateprivileges=deny,spawn=deny,resourcecontrol=deny \ -msg timestamp=on 2020-03-28 18:41:52.990+0000: Domain id=1 is tainted: high-privileges 2020-03-28 18:41:52.990+0000: Domain id=1 is tainted: host-cpu char device redirected to /dev/pts/0 (label charserial0) 2020-03-28T18:41:55.500662Z qemu-system-x86_64: vfio: Cannot reset device 0000:03:00.0, depends on group 18 which is not owned. 2020-03-28T18:41:56.562831Z qemu-system-x86_64: vfio: Cannot reset device 0000:03:00.0, depends on group 18 which is not owned. 2020-03-28T18:42:20.154799Z qemu-system-x86_64: terminating on signal 15 from pid 5718 (/usr/sbin/libvirtd) 2020-03-28 18:42:21.755+0000: shutting down, reason=destroyed Edited April 24, 2020 by sub6 Solved added. Quote Link to comment
testdasi Posted March 28, 2020 Share Posted March 28, 2020 Tools -> Diagnostics -> attach zip file Also copy-paste the PCIe devices section in Tools -> System Devices And copy-paste your xml Quote Link to comment
sub6 Posted March 30, 2020 Author Share Posted March 30, 2020 This is the XML of a once started VM, which after stopping the VM won't boot anymore. I created a new one called "Toller Name", which i then started. PCIe Devices IOMMU group 0: [1022:1482] 00:01.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 1: [1022:1483] 00:01.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 2: [1022:1483] 00:01.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 3: [1022:1482] 00:02.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 4: [1022:1482] 00:03.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 5: [1022:1483] 00:03.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse GPP Bridge IOMMU group 6: [1022:1482] 00:04.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 7: [1022:1482] 00:05.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 8: [1022:1482] 00:07.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 9: [1022:1484] 00:07.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 10: [1022:1482] 00:08.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Host Bridge IOMMU group 11: [1022:1484] 00:08.1 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 12: [1022:1484] 00:08.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 13: [1022:1484] 00:08.3 PCI bridge: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Internal PCIe GPP Bridge 0 to bus[E:B] IOMMU group 14: [1022:790b] 00:14.0 SMBus: Advanced Micro Devices, Inc. [AMD] FCH SMBus Controller (rev 61) [1022:790e] 00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51) IOMMU group 15: [1022:1440] 00:18.0 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 0 [1022:1441] 00:18.1 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 1 [1022:1442] 00:18.2 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 2 [1022:1443] 00:18.3 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 3 [1022:1444] 00:18.4 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 4 [1022:1445] 00:18.5 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 5 [1022:1446] 00:18.6 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 6 [1022:1447] 00:18.7 Host bridge: Advanced Micro Devices, Inc. [AMD] Matisse Device 24: Function 7 IOMMU group 16: [144d:a808] 01:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM981/PM981/PM983 IOMMU group 17: [1022:43d5] 03:00.0 USB controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset USB 3.1 XHCI Controller (rev 01) IOMMU group 18: [1022:43c8] 03:00.1 SATA controller: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset SATA Controller (rev 01) IOMMU group 19: [1022:43c6] 03:00.2 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Bridge (rev 01) IOMMU group 20: [1022:43c7] 20:00.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) IOMMU group 21: [1022:43c7] 20:01.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) IOMMU group 22: [1022:43c7] 20:04.0 PCI bridge: Advanced Micro Devices, Inc. [AMD] 400 Series Chipset PCIe Port (rev 01) IOMMU group 23: [10ec:8168] 22:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15) IOMMU group 24: [10de:13c2] 26:00.0 VGA compatible controller: NVIDIA Corporation GM204 [GeForce GTX 970] (rev a1) IOMMU group 25: [10de:0fbb] 26:00.1 Audio device: NVIDIA Corporation GM204 High Definition Audio Controller (rev a1) IOMMU group 26: [1022:148a] 27:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse PCIe Dummy Function IOMMU group 27: [1022:1485] 28:00.0 Non-Essential Instrumentation [1300]: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP IOMMU group 28: [1022:1486] 28:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP IOMMU group 29: [1022:149c] 28:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller IOMMU group 30: [1022:1487] 28:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller IOMMU group 31: [1022:7901] 30:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) IOMMU group 32: [1022:7901] 31:00.0 SATA controller: Advanced Micro Devices, Inc. [AMD] FCH SATA Controller [AHCI mode] (rev 51) XML <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>Gaming VM</name> <uuid>882a2df3-98ef-3ff4-bb44-c6af166472d1</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>12582912</memory> <currentMemory unit='KiB'>12582912</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>10</vcpu> <cputune> <vcpupin vcpu='0' cpuset='1'/> <vcpupin vcpu='1' cpuset='7'/> <vcpupin vcpu='2' cpuset='2'/> <vcpupin vcpu='3' cpuset='8'/> <vcpupin vcpu='4' cpuset='3'/> <vcpupin vcpu='5' cpuset='9'/> <vcpupin vcpu='6' cpuset='4'/> <vcpupin vcpu='7' cpuset='10'/> <vcpupin vcpu='8' cpuset='5'/> <vcpupin vcpu='9' cpuset='11'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-4.2'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/882a2df3-98ef-3ff4-bb44-c6af166472d1_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='5' threads='2'/> <cache mode='passthrough'/> <feature policy='require' name='topoext'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <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='block' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source dev='/dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSADB30857W'/> <target dev='hdc' bus='sata'/> <boot order='1'/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/virtio-win-0.1.173-2.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:ad:5e:2e'/> <source bridge='virbr0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' 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='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x26' slot='0x00' function='0x0'/> </source> <rom file='/mnt/user/isos/AsusStrix_GTX970.rom'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x26' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <memballoon model='none'/> </devices> </domain> clusterfuck-diagnostics-20200330-1755.zip Quote Link to comment
testdasi Posted March 30, 2020 Share Posted March 30, 2020 Try to see if your VM would boot without the USB controller. I think it's the USB controller that prevents it from rebooting as it can't be reset. 03:00.0 is USB 3.1 controller, which is typically not pass-through-able. 28:00.3 is USB 3.0 which probably will give your better luck. Before trying the 28:00.3 though, go to the app store and install VFIO-PCI Config plugin then settings -> VFIO-PCI.CFG and look for the 2 USB controllers. It will tell you which USB device is plugged into which controller. Make sure the USB stick is NOT plugged into the controller to be passed through. If you picked 03:00.0 because your USB stick is plugged into 28:00.3 then you need to use a different port (preferably USB 2.0 port). To test which port is on which controller, you use a mouse or ANOTHER USB stick and just refresh the VFIO-PCI.CFG page for each port. (Hint: usually ports in the same "block" in the rear panel are connected to the same controller). Quote Link to comment
sub6 Posted April 1, 2020 Author Share Posted April 1, 2020 Thank you for your fast reply. 👏 Now I tried a few other things, but sadly still not successful. 1. I created a new libvirt.img at /mnt/cache/system/libvirt/libvirt.img -> Then recreated a Windows 10 VM started successfully, rebooted and failed. 2. I removed the USB controller completely from my syslinux config. Rebooted Unraid, recreated a Windows 10 VM started successfully, rebooted and failed. So I think the problem is not from the USB Controller? When looking at the libvirt log I see the following: 2020-04-01 08:29:26.813+0000: 5768: info : libvirt version: 5.10.0 2020-04-01 08:29:26.813+0000: 5768: info : hostname: clusterfuck 2020-04-01 08:29:26.813+0000: 5768: warning : qemuDomainObjTaint:9301 : Domain id=1 name='Windows 10' uuid=46871f70-f464-52f5-0d5c-453ceb3f1d6e is tainted: high-privileges 2020-04-01 08:29:26.813+0000: 5768: warning : qemuDomainObjTaint:9301 : Domain id=1 name='Windows 10' uuid=46871f70-f464-52f5-0d5c-453ceb3f1d6e is tainted: host-cpu 2020-04-01 08:29:42.418+0000: 5766: error : virProcessRunInFork:1159 : internal error: child reported (status=125): 2020-04-01 08:29:42.418+0000: 5766: warning : qemuBlockRemoveImageMetadata:2604 : Unable to remove disk metadata on vm Windows 10 from /dev/disk/by-id/ata-Samsung_SSD_840_EVO_250GB_S1DBNSADB30857W (disk target hdc) Quote Link to comment
bastl Posted April 1, 2020 Share Posted April 1, 2020 @sub6 Try to connect the 840-Evo to another sata port so it's on one of the other controllers. Your IOMMU groups show you have one controller in the chipset (group 18) and 2 extra controllers (group 31+32) for sata. I had similiar issues with passthrough of one of my onboard network nics, which without ACS patch are grouped together with a sata controller, USB controller and other devices connected to the chipset. With ACS patch applied it showed up in it's own group but the passthrough wasn't stable. VMs crashed or the nic disapeared or dropped connections. Maybe that helps. On 3/28/2020 at 9:24 PM, sub6 said: 2020-03-28T18:41:55.500662Z qemu-system-x86_64: vfio: Cannot reset device 0000:03:00.0, depends on group 18 which is not owned. 2020-03-28T18:41:56.562831Z qemu-system-x86_64: vfio: Cannot reset device 0000:03:00.0, depends on group 18 which is not owned. This clearly shows that the passed through USB controller somehow still relies on the next group where a sata controller is in. Quote Link to comment
sub6 Posted April 2, 2020 Author Share Posted April 2, 2020 (edited) @bastlas suggested I moved the 840 Evo to the only other available SATA Port. But that sadly did not change anything. How can i find out if the SSD is move to the right controller? @testdasi I tried using the other USB Controller (28:00.3) which gives me the same problem as described here (for the Sound Card 28:00.2). Unraid kind of freezes, I think this is due to the other Devices (maybe 28:00.0 Non-Essential Instrumentation or 28:00.1 Encryption controller) Nonetheless I think the problem must be something else than the USB Controller. Since I tried the VM without the USB controller and also removed the PCI Device (03:00.0) for Passthrough from the Syslinux Config. The problem started as I remember when switching to 6.9, but going back to 6.8.x did not resolve the problem. EDIT: Could it possibly come from a GPU Driver update? Do those also update the FW? I have done one in the past. Edited April 2, 2020 by sub6 Quote Link to comment
bastl Posted April 2, 2020 Share Posted April 2, 2020 (edited) 1 hour ago, sub6 said: as suggested I moved the 840 Evo to the only other available SATA Port. But that sadly did not change anything. How can i find out if the SSD is move to the right controller? If you boot unraid in GUI mode you should be able to use "lstopo" to generate an overview to see how devices are connected together. Example output: Edit: Adjust the path for your needs so you can find the picture. lstopo /mnt/user/appdata/topology.png Edited April 2, 2020 by bastl Quote Link to comment
sub6 Posted April 2, 2020 Author Share Posted April 2, 2020 @bastlHere is the image. I guess all the four SATA Ports of my mainboard are connected to the same controller. The thing that wonders me is that even without USB Controller Pass trough this problem occurs. So I hope it is not connected to the SATA Controller. Quote Link to comment
bastl Posted April 2, 2020 Share Posted April 2, 2020 @sub6 Your IOMMU groups (31+32) shows another SATA controller. You can see them in the lstopo as well (PCI 1022:7901). Could be that your motherboard already has the controller on board without physical connections, reserved for higher tier boards. Thats what confused me. So, forget about that. If you have another ssd or an old hdd laying around, I would test the passthrough with another disk and the same xml. Not sure, but in the past users with some intel ssd's had issues as well. Can't remember which model. Maybe it's an specific thing with this Samsung SSD and your SATA controller. Quote Link to comment
sub6 Posted April 3, 2020 Author Share Posted April 3, 2020 (edited) @bastl @testdasi The next piece of the puzzle. I compared the XML Files of the VM before first startup and after shutdown. In total there are 26 differences. Attached is the Output of ExamDiff as an HTML file. This shows the differnces: XML_Diff.html Edited April 6, 2020 by sub6 Quote Link to comment
sub6 Posted April 6, 2020 Author Share Posted April 6, 2020 (edited) Push🙃 Any Ideas? The current situation is quite anyoing. I have to manually create a new VM on every boot. Can I newly install the KVM parts of Unraid? Edited April 6, 2020 by sub6 Quote Link to comment
testdasi Posted April 6, 2020 Share Posted April 6, 2020 Unraid freezes when you passed through 28:00.3 probably because the Unraid USB stick is on it. I provided instruction on how to identify what port is on which controller, which I don't think you have followed. Your problem is kinda unusual so logically the cause should be something uncommon. And the one thing that is uncommon about your config is that you passed through the USB 3.1 controller, which nobody has ever successfully done so - at least none that I have seen on here. 100% load on 1 core and being stuck on Tianocore screen CAN be the symptoms the controller failure to handshake with the USB devices. And a non-resetting / problematic controller will fail to handshake with USB devices. So 03:00.0 is the primary candidate of your issue but your refusal to remove it from the config is not helping at all. Remove it from your config and see if the problem still occurs. Quote Link to comment
sub6 Posted April 6, 2020 Author Share Posted April 6, 2020 (edited) On 4/1/2020 at 10:31 AM, sub6 said: 2. I removed the USB controller completely from my syslinux config. Rebooted Unraid, recreated a Windows 10 VM started successfully, rebooted and failed. So I think the problem is not from the USB Controller? @testdasi I have tried that. And I put the USB Stick in another port, when changing to the other USB controller. Edited April 6, 2020 by sub6 Quote Link to comment
testdasi Posted April 6, 2020 Share Posted April 6, 2020 25 minutes ago, sub6 said: @testdasi I have tried that. And I put the USB Stick in another port, when changing to the other USB controller. Removing it from syslinux will only stop it from appearing on the Other PCI Device section of the VM template. Your existing VM config would still have it and thus when you start the VM, it would still pass through. This is apparent in your latest xml diff, which contains the config to pass through 03:00.0. If you are comfortable with deleting the xml section then do it manually via xml edit. Otherwise, I would suggest starting a new template from scratch (perhaps copy-paste the xml here as well so everyone is on the same page with regards to which VM you are testing). Quote Link to comment
sub6 Posted April 6, 2020 Author Share Posted April 6, 2020 After removing it from the syslinux config, I also created a new VM (as always 🙂. Since I did not had it in my syslinux config, I could not choose it (other PCI devices) when creating the VM. I then selected mouse and keyboard as USB Devices. The funny thing is, that I can succesfully pass trough the USB controller. Hot Plug devices in the VM. And since the problem did not resolve itself when exluding the USB controller (from VM config and syslinux config), I though it should not be the source of the problem. Thank you for beeing patient with me. 😊 Quote Link to comment
sub6 Posted April 23, 2020 Author Share Posted April 23, 2020 (edited) @testdasi @bastl I fixed it by doing a fresh install on another USB Stick. After that I transferred my config and syslinux. Restarted a suddenly I can restart the VMs. Also after adding the controller to my syslinux again I can successfully parse it to the VM. I think during the update, and later downgrade some file for the KVM Support must have broken. And going up and down between releases did not fix it. Now I am happy again with my Unraid System. Thank you two for your help. Maybe some else can use this thread. Edited April 24, 2020 by sub6 1 Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.