ryoko227

Latest updates.. 2nd machine is running for over 5 days with no issues. VM still runs like a champ, I'd roughly estimate (just by feel) 96% bare-metal performance. System log shows smooth sailing. Extremely happy with it, and I haven't even gotten into the juicy dockers and plugins yet. 1st machine (problem child) this post was originally about... So I pulled off all the files and did a from scratch reformat and clean install of everything. Array disks, cache, and the unraid flash drive. Everything. I reinstalled directly to beta 21 and unraid seemed to be doing alright, minus a nagging usb error I had seen since I started building this rig back on 6.19. My VMs still had the same previous issues, though I could not get an OVMF Win10 to install. I decided to just start playing with the MB CMOS settings and ended up getting it locked into UEFI without usb legacy support (whoops) which lead me to jumper clearing the BIOS. After doing a CMOS default settings reset, I was amazed to see how quickly unraid booted on this machine (fastest its ever gone). I also noticed that the previous usb error message mentioned above was also gone. Unraid now seems to run solid on this machine. I'm having zero issues with file transfers into and out of VMs so-far, and I haven't had a lockup yet. The only strange thing is that when I try to install a Win10 VM, I still can't use the stable 112-1 virtio drivers (weird media error for all the files), yet i can "downgrade" them from inside the VM. Installing to Win8.1 first, then using the 112-1 virtio drivers seems to work though, but I have not yet done an upgrade to win10 from 8 yet (tonight maybe.) I'm also not get 60FPS on WT in the VM with a GTX960, when the other server VM can do it on with a GTX950 no problem. I'm hesitant to say that my issues are fixed yet though as this machine just doesn't "feel right" just yet, but I/we can't exactly diagnose a feeling till an error actually rears its head. That being said, resetting my bios to default again seems to have resolved MANY of the issues I was having.

Sorry about that, I have been doing cache only for the vdisk share which is on the SSD (cache only selected) formated as btrfs. I intend to expand the pool at some point once all of this is up and running Disk shares were set to Auto, and I had the vdisk share export set to yes. After disabling them, I also decided to disable Dockers and removed the image and share for it (I'm not using it at the moment anyways). When testing out the Seabios VM, it still hits CPU0 to 100% during games and I was able to make that VM crash by trying to run a program from a public exported share on the array. Unfortunately though, unraid completely locked up before I could grab the diagnostic from it. Also, somewhere during these changes and tests, my OVMF VM on the same vdisk share died as well. I tried the fs0:, but there are no directories listed after that to try and force a boot. I will put together another OVMF vdisk tomorrow after work and try to grab a diagnostic when it crashes then. EDIT: Interesting side note... I am also setting up a second unraid server with roughly similar hardware, though this install originated from 6.2 beta 21 and used the virtio drivers downloaded directly through the unraid webgui (112-1 I think). I've had absolutely no issues on this second server (after setting up the vbios.rom and the msi interrupts). Shares can be IO without issue, external pc's can see and access the shares without user/pw prompts, etc. The win10VM runs 100% solid on OVMF bios, and has not crashed once in something like 6 hours of testing. Warthunder seems to bang away at CPU0 still, but I'm starting to think that is related to that particular software in a virtual environment, as Adobe premier, etc. spread the work load across CPUs with no issues. Basically, this second server setup has run ~100% "straight out of the box". I'm wondering if some settings, corruptions, etc. might have been carried over from the 6.19 upgrade on the 1st server this post was originally made about. I plan on doing a complete clean install and reformatting of the drives when I get home tonight and see if this solves the previous issues *fingers crossed*. If not, I will post the diagnostics after a crash.

I made reference to this issue in another post located here, but thought better to focus on the issues related to OVMF and beta 21 that I'm having here. http://lime-technology.com/forum/index.php?topic=48241.0 When I try to transfer files around the shares from the VM's vdisks or access them from the primary/secondary vdisk, my Win10 OVMF-440 VM crashes, looses ability to find files, crashes unraid, etc. For the first time tonight I was able to successfully transfer 22GB from a share to the primary vdisk without this sort of crash. However, shortly afterwards while trying to access and update the game located in those folders, I started getting multiple: file does not exist, cannot find specified files, etc. type of errors. Attached is the diagnostics file from after when the VM started acting strangely. For ease of use, I will also repost the xml and VM log as well. The system is... MB- MSI X99A SLI Plus CPU- Intel Xeon E5 2670 V3 Mem- 2x8GB Kingston DDR4-2133 GPU- (2) MSI GTX960 GAMING 4G SSD- (1) 250GB SK hynix (cache) HDD-(2) 3TB Seagate (parity and storage) I have Dockers activated, but nothing installed. Only the 2 default plugins, and have only added the vrom tag to the XML file. XML <domain type='kvm' id='1'> <name>Win10OVMF</name> <uuid>685fc4b3-40bb-64df-d571-cdf37b27f929</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>7340032</memory> <currentMemory unit='KiB'>7340032</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>10</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='3'/> <vcpupin vcpu='2' cpuset='4'/> <vcpupin vcpu='3' cpuset='5'/> <vcpupin vcpu='4' cpuset='6'/> <vcpupin vcpu='5' cpuset='14'/> <vcpupin vcpu='6' cpuset='15'/> <vcpupin vcpu='7' cpuset='16'/> <vcpupin vcpu='8' cpuset='17'/> <vcpupin vcpu='9' cpuset='18'/> </cputune> <resource> <partition>/machine</partition> </resource> <os> <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/685fc4b3-40bb-64df-d571-cdf37b27f929_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor id='none'/> </hyperv> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='5' threads='2'/> </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='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/vdisks/Win10OVMF/vdisk1.img'/> <backingStore/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <alias name='virtio-disk2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/OS iso/Windows 10 Pro 64bit.iso'/> <backingStore/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <alias name='sata0-0-0'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/virtio iso/virtio-win-0.1.113.iso'/> <backingStore/> <target dev='hdb' bus='sata'/> <readonly/> <alias name='sata0-0-1'/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='nec-xhci'> <alias name='usb'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <controller type='pci' index='0' model='pci-root'> <alias name='pci.0'/> </controller> <controller type='sata' index='0'> <alias name='sata0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <controller type='virtio-serial' index='0'> <alias name='virtio-serial0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:1f:4d:ff'/> <source bridge='br0'/> <target dev='vnet0'/> <model type='virtio'/> <alias name='net0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <source path='/dev/pts/0'/> <target port='0'/> <alias name='serial0'/> </serial> <console type='pty' tty='/dev/pts/0'> <source path='/dev/pts/0'/> <target type='serial' port='0'/> <alias name='serial0'/> </console> <channel type='unix'> <source mode='bind' path='/var/lib/libvirt/qemu/channel/target/domain-Win10OVMF/org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0' state='connected'/> <alias name='channel0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <alias name='hostdev0'/> <rom file='/boot/vbios.rom'/> <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='0x1'/> </source> <alias name='hostdev1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x056e'/> <product id='0x0035'/> <address bus='5' device='3'/> </source> <alias name='hostdev2'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x1c4f'/> <product id='0x0002'/> <address bus='5' device='8'/> </source> <alias name='hostdev3'/> </hostdev> <memballoon model='virtio'> <alias name='balloon0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </memballoon> </devices> </domain> VM log 2016-04-11 10:46:00.476+0000: starting up libvirt version: 1.3.1, qemu version: 2.5.1, hostname: Beast LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/ QEMU_AUDIO_DRV=none /usr/local/sbin/qemu -name Win10OVMF -S -machine pc-i440fx-2.5,accel=kvm,usb=off,mem-merge=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=none -drive file=/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/etc/libvirt/qemu/nvram/685fc4b3-40bb-64df-d571-cdf37b27f929_VARS-pure-efi.fd,if=pflash,format=raw,unit=1 -m 7168 -realtime mlock=on -smp 10,sockets=1,cores=5,threads=2 -uuid 685fc4b3-40bb-64df-d571-cdf37b27f929 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-Win10OVMF/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-hpet -no-shutdown -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x7 -device ahci,id=sata0,bus=pci.0,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/mnt/usio-pci,host=03:00.0,id=hostdev0,bus=pci.0,addr=0x6,romfile=/boot/vbios.rom -device vfio-pci,host=03:00.1,id=hostdev1,bus=pci.0,addr=0x8 -device usb-host,hostbus=5,hostaddr=3,id=hostdev2 -device usb-host,hostbus=5,hostaddr=8,id=hostdev3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -msg timestamp=on Domain id=1 is tainted: high-privileges Domain id=1 is tainted: host-cpu char device redirected to /dev/pts/0 (label charserial0) 2016-04-11T12:02:53.561741Z qemu-system-x86_64: terminating on signal 15 from pid 6261 2016-04-11 12:02:53.756+0000: shutting down beast-diagnostics-20160411-1950.zip

Hmm, I don't think I've run into that issue specifically. But I did try moving a ton of files over the network via between the public exported shares; I can move files with no issues even when the VMs running. So it would seem to be specifically related to the VM's and how they are interacting with the shares/file system. I thought that the Seabios VM was working properly, but I decided to do some more testing and randomly pushed a bunch of files around the shares which ultimately crashed the VM (locked up). I tried to force shutdown via the webgui as unraid was still running and got this error "Failed to terminate process 8853 with SIGKILL: Device or resource busy." After a few more attempts I tried to stop the array which then locked up unraid and I had to hard reboot. Running a VM using OVMF is much worse in the sense that it will reboot the VM, or lockup even with small file transfers, much more frequently. So the current situation running my Win10 VMs are... 6.19 Seabios most stable, but running apps/games are almost impossible due to 100% cpu usage on "CPU0" 6.19 OVMF completely unstable, crashes and reboots regularly 6.2 beta 21 Seabios mostly stable (can lock up transferring files), still bangs away at "CPU0" but apps and games are "usable", still not baremetal 6.2 beta 21 OVMF OS seems to be mostly stable, have noticed some strange system has changed messages. Utterly unstable during file transfers

OVMF VM on 440: This one has been interesting to say the least. Trying to install with a 2nd vdisk attached crashed the install once, and locked up unraid more than once while trying to transfer to it. It also had the strange effect of dumping the GPU compeletly at one point. As in, you couldn't even find it in device manager. So i decided to try installing without the 2nd vdisk and was actually able to get it up and running. Here is the XML and log file before adding the 2nd vdisk. XML <domain type='kvm'> <name>Windows 10</name> <uuid>a86b24ff-c13e-69ff-3b98-f3b5cf4c4532</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>7340032</memory> <currentMemory unit='KiB'>7340032</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>10</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='3'/> <vcpupin vcpu='2' cpuset='4'/> <vcpupin vcpu='3' cpuset='5'/> <vcpupin vcpu='4' cpuset='6'/> <vcpupin vcpu='5' cpuset='14'/> <vcpupin vcpu='6' cpuset='15'/> <vcpupin vcpu='7' cpuset='16'/> <vcpupin vcpu='8' cpuset='17'/> <vcpupin vcpu='9' cpuset='18'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/a86b24ff-c13e-69ff-3b98-f3b5cf4c4532_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor id='none'/> </hyperv> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='5' threads='2'/> </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='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/vdisks/Windows 10/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/OS iso/Windows 10 Pro 64bit.iso'/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/virtio iso/virtio-win-0.1.113.iso'/> <target dev='hdb' bus='sata'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='nec-xhci'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <controller type='pci' index='0' model='pci-root'/> <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:a8:d7:4b'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <source mode='connect'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <rom file='/boot/vbios.rom'/> <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='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x056e'/> <product id='0x0035'/> </source> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x1c4f'/> <product id='0x0002'/> </source> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </memballoon> </devices> </domain> Log file 2016-04-09 05:17:54.622+0000: starting up libvirt version: 1.3.1, qemu version: 2.5.1, hostname: Beast LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/ QEMU_AUDIO_DRV=none /usr/local/sbin/qemu -name 'Windows 10' -S -machine pc-i440fx-2.5,accel=kvm,usb=off,mem-merge=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=none -drive file=/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/etc/libvirt/qemu/nvram/a86b24ff-c13e-69ff-3b98-f3b5cf4c4532_VARS-pure-efi.fd,if=pflash,format=raw,unit=1 -m 7168 -realtime mlock=on -smp 10,sockets=1,cores=5,threads=2 -uuid a86b24ff-c13e-69ff-3b98-f3b5cf4c4532 -nographic -no-user-config -nodefaults -chardev 'socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-Windows 10/monitor.sock,server,nowait' -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-hpet -no-shutdown -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x7 -device ahci,id=sata0,bus=pci.0,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive '0 -device vfio-pci,host=03:00.0,id=hostdev0,bus=pci.0,addr=0x6,romfile=/boot/vbios.rom -device vfio-pci,host=03:00.1,id=hostdev1,bus=pci.0,addr=0x8 -device usb-host,hostbus=5,hostaddr=3,id=hostdev2 -device usb-host,hostbus=5,hostaddr=8,id=hostdev3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x9 -msg timestamp=on Domain id=1 is tainted: high-privileges Domain id=1 is tainted: host-cpu char device redirected to /dev/pts/0 (label charserial0) I tried attaching a new 2nd vdisk at this point and the VM rebooted itself once and came up without a GPU or Audio device listed. I left the VM running while I was typing these messages and randomly about 10-15 minutes later the display auto switched to 1080p and the display adapter was available again..... I clean installed the nvidia drivers as the audio was not working, then tried to copy some files over and bam... VM crashed with an error on the unraid web gui, but nothing showed up in the log file. Here are the xml and log files after adding and "formatting" the 2nd vdisk, including the crash. XML <domain type='kvm'> <name>Windows 10</name> <uuid>a86b24ff-c13e-69ff-3b98-f3b5cf4c4532</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>7340032</memory> <currentMemory unit='KiB'>7340032</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>10</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='3'/> <vcpupin vcpu='2' cpuset='4'/> <vcpupin vcpu='3' cpuset='5'/> <vcpupin vcpu='4' cpuset='6'/> <vcpupin vcpu='5' cpuset='14'/> <vcpupin vcpu='6' cpuset='15'/> <vcpupin vcpu='7' cpuset='16'/> <vcpupin vcpu='8' cpuset='17'/> <vcpupin vcpu='9' cpuset='18'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/a86b24ff-c13e-69ff-3b98-f3b5cf4c4532_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor id='none'/> </hyperv> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='5' threads='2'/> </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='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/vdisks/Windows 10/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/ArrayVdisks/Windows 10/vdisk2.img'/> <target dev='hdd' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/OS iso/Windows 10 Pro 64bit.iso'/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/virtio iso/virtio-win-0.1.113.iso'/> <target dev='hdb' bus='sata'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='nec-xhci'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <controller type='pci' index='0' model='pci-root'/> <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:a8:d7:4b'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <source mode='connect'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <rom file='/boot/vbios.rom'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x056e'/> <product id='0x0035'/> </source> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x1c4f'/> <product id='0x0002'/> </source> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </memballoon> </devices> </domain> Log File (it doesn't even show an error, just that it received a terminating signal) 2016-04-09T08:03:56.188788Z qemu-system-x86_64: terminating on signal 15 from pid 3347 2016-04-09 08:03:56.462+0000: shutting down 2016-04-09 08:07:08.671+0000: starting up libvirt version: 1.3.1, qemu version: 2.5.1, hostname: Beast LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/ QEMU_AUDIO_DRV=none /usr/local/sbin/qemu -name 'Windows 10' -S -machine pc-i440fx-2.5,accel=kvm,usb=off,mem-merge=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=none -drive file=/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=/etc/libvirt/qemu/nvram/a86b24ff-c13e-69ff-3b98-f3b5cf4c4532_VARS-pure-efi.fd,if=pflash,format=raw,unit=1 -m 7168 -realtime mlock=on -smp 10,sockets=1,cores=5,threads=2 -uuid a86b24ff-c13e-69ff-3b98-f3b5cf4c4532 -nographic -no-user-config -nodefaults -chardev 'socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-Windows 10/monitor.sock,server,nowait' -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-hpet -no-shutdown -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x7 -device ahci,id=sata0,bus=pci.0,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive ',path=/var/lib/libvirt/qemu/channel/target/domain-Windows 10/org.qemu.guest_agent.0,server,nowait' -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=org.qemu.guest_agent.0 -device vfio-pci,host=03:00.0,id=hostdev0,bus=pci.0,addr=0x8,romfile=/boot/vbios.rom -device vfio-pci,host=03:00.1,id=hostdev1,bus=pci.0,addr=0x9 -device usb-host,hostbus=5,hostaddr=3,id=hostdev2 -device usb-host,hostbus=5,hostaddr=8,id=hostdev3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xa -msg timestamp=on Domain id=8 is tainted: high-privileges Domain id=8 is tainted: host-cpu char device redirected to /dev/pts/0 (label charserial0) I'm going to try some file transfers on this VM prior to adding the 2nd vdisk and see if I can make it lock up from there. I also noticed that when the VM is loading that the network connection is always the last thing to load since its so slow. Wondering if that is an indication of another issue.

So I tried the ideas I had (listed above) for 6.19 and the results were the same. Seabios would bang away on CPU0 in Windows with system crippling performance, and OVMF would just randomly lock up whenever it felt like it. I tried with a Q35 machine and it ran, but even worse than the 440. Late last night I saw Jon's post and went for the update. I'm not going to bother with 6.19 from this point as no matter what I've tried it just hasn't really worked. So after upgrading to 6.2 beta 21 here is the current status. I could no longer use the 102 virtio drivers as Win10 install was now stating that it could not be installed on this media after the stor driver was loaded. I used the latest virtio 113 iso from here on in. I then ran into an issue where Seabios and OVMF installs would lockup unRaid trying to transfer files to the second vdisk (for games, etc.). This made me wonder if it was something specific to the share I had setup. For some reason, the share Arrayvdisk (which I had set to "cache-only" in 6.19) was set to "cache-no" in this unraid version. I cleared and deleted the share and remade it cache only which then lead to the differing results below. Also note, that I am one of the people who for whatever reason everytime when I edit the VM via the gui, it dumps the primary vdisk information and I have to re-add it. Seabios VM on 440: Runs but has the same issues as in 6.19 (CPU0 doing 100% nearly 99% of the time), however programs are now able to run at this point. So this is a marked improvement! Though, now instead of massive machine crippling pauses, there are micro stutters (10th of a sec -> 2 secs) when that CPU hits 100%. Here are the XML and Log files for this VM. I have not done exhaustive testing on this VM in regards to file transfers, but I was able to copy over about 30GB to the 2nd vdisk which was impossible before on OVMF 6.19. At this point, the VM appears to be stable but definitely not perfect nor close to baremetal. XML <domain type='kvm'> <name>Win10Sea</name> <uuid>292e54e5-9644-cb7f-ae95-b8b3a063fca8</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>7340032</memory> <currentMemory unit='KiB'>7340032</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>10</vcpu> <cputune> <vcpupin vcpu='0' cpuset='1'/> <vcpupin vcpu='1' cpuset='2'/> <vcpupin vcpu='2' cpuset='3'/> <vcpupin vcpu='3' cpuset='4'/> <vcpupin vcpu='4' cpuset='5'/> <vcpupin vcpu='5' cpuset='13'/> <vcpupin vcpu='6' cpuset='14'/> <vcpupin vcpu='7' cpuset='15'/> <vcpupin vcpu='8' cpuset='16'/> <vcpupin vcpu='9' cpuset='17'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-2.5'>hvm</type> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor id='none'/> </hyperv> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='5' threads='2'/> </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='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/vdisks/Win10Sea/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/ArrayVdisks/Win10Sea/vdisk2.img'/> <target dev='hdd' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/OS iso/Windows 10 Pro 64bit.iso'/> <target dev='hda' bus='sata'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/ISOs/virtio iso/virtio-win-0.1.113.iso'/> <target dev='hdb' bus='sata'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='nec-xhci'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0'/> </controller> <controller type='pci' index='0' model='pci-root'/> <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:f0:5e:a0'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <source mode='connect'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='pci' managed='yes' xvga='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x0'/> </source> <rom file='/boot/vbios.rom'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x03' slot='0x00' function='0x1'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x056e'/> <product id='0x0035'/> </source> </hostdev> <hostdev mode='subsystem' type='usb' managed='no'> <source> <vendor id='0x1c4f'/> <product id='0x0002'/> </source> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x0a' function='0x0'/> </memballoon> </devices> </domain> Log 2016-04-09 07:29:50.502+0000: starting up libvirt version: 1.3.1, qemu version: 2.5.1, hostname: Beast LC_ALL=C PATH=/bin:/sbin:/usr/bin:/usr/sbin HOME=/ QEMU_AUDIO_DRV=none /usr/local/sbin/qemu -name Win10Sea -S -machine pc-i440fx-2.5,accel=kvm,usb=off,mem-merge=off -cpu host,hv_time,hv_relaxed,hv_vapic,hv_spinlocks=0x1fff,hv_vendor_id=none -m 7168 -realtime mlock=on -smp 10,sockets=1,cores=5,threads=2 -uuid 292e54e5-9644-cb7f-ae95-b8b3a063fca8 -nographic -no-user-config -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/domain-Win10Sea/monitor.sock,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=localtime -no-hpet -no-shutdown -boot strict=on -device nec-usb-xhci,id=usb,bus=pci.0,addr=0x7 -device ahci,id=sata0,bus=pci.0,addr=0x3 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive file=/mnt/user/vdisks/Win10Sea/vdisk1.img,format=raw,if=none,id=drive-virtio-disk2,cache=writeback -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk2,id=virtio-disk2,bootindex=1 -drive file=/mnt/user/ArrayV0,id=hostdev0,x-vga=on,bus=pci.0,addr=0x8,romfile=/boot/vbios.rom -device vfio-pci,host=03:00.1,id=hostdev1,bus=pci.0,addr=0x9 -device usb-host,hostbus=5,hostaddr=3,id=hostdev2 -device usb-host,hostbus=5,hostaddr=8,id=hostdev3 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0xa -msg timestamp=on Domain id=6 is tainted: high-privileges Domain id=6 is tainted: host-cpu char device redirected to /dev/pts/0 (label charserial0) I will post the OVMF test in the next post as I hit 20000char ^^;

I had been reading, searching, learning how to setup my unRaid server for a few months prior to actually taking the plunge and buying my hardware and software for my home media/gaming/NAS server. Since I purchased everything and started setting it up about a week ago, I have been able to resolve all of my issues using the posts in this awesome forum as my guide. That is until now. Since my issues span over two different versions of unRaid, I thought placing this thread here would be the best bet. My system specs are: MB- MSI X99A SLI Plus CPU- Intel Xeon E5 2670 V3 Mem- 2x8GB Kingston DDR4-2133 GPU- (2) MSI GTX960 GAMING 4G SSD- (1) 250GB SK hynix (cache) HDD-(2) 3TB Seagate (parity and storage) My current issues are (setups listed below): If using unRaid 6.19 Seabios Win10Pro64 VMs: runs completely stable with no crashes over days of use, however when running any application or game the performance grinds to a halt. Windows performance monitor shows CPU0 (displayed as CPU0 by windows, I keep CPU0 free in the VM setup for unRaid) being run at 100% while the other cores (no matter how few or many are assigned) drop down to just about idle. If CPU0 affinity is turned off, work is distributed across the other cores, but the application will generally crash. If left alone applications will frequently timeout. Even if the application does manage to successfully load, the performance is visually equitable to that of my 10 year old 1st gen i3 laptop. If using unRaid 6.19 OVMF Win10Pro64 VMs: it is nearly impossible to correctly test as the VM will lockup randomly and intermittently (sometimes during OS install, sometimes after a reboot, sometimes when just sitting idle). Usually kicking all of the peripheral devices (pass-through mouse/keyboard). I have not been able to even install or run a game to see the performance in this mode due to instability and crashing issues. unRaid continues to run and network drives are still accessible, only the VM itself seems to die. Also, restarts will eventually break the VM and make it completely unbootable even using the console commands. If using unRaid 6.2 beta 20 OVMF or Seabios Win10Pro64 VMs: the performance is OUTSTANDING! I cannot notice any difference visually between this VM’s gaming performance and the bare metal machine. Also, I am able to use OVMF without the issues listed above for 6.19. However, using either bios type, the server/VM are completely unstable and will regularly lock up the entire unRaid server (can’t even power down from console or ssh) seemingly during file transfers between the unRaid shares and the VM’s 2nd vdisk. I have not seen/noticed a lockup outside of transferring/accessing files. I’m not really sure what to do at this point. 6.2 beta 20 obviously fixes whatever the issue with the performance was, but then introduces severe instability. I’ve tried every combination of CPU cores, OS, and OVMF/Seabios setups on 6.19 that I can think of, and the same poor performance issues listed above can be found on all of them. Can anyone lend any suggestions on things to try, or has any ideas of what might be causing these issues? I’ll list the things I have done below to give a better idea of where everything stands. Current setup: Using latest virtio drivers - virtio-win-0.1.113 ?iso shows as 1.111 on the mounted drive though. Is that normal? As the 2 NVidia GPU’s are in slots 1 & 3, I have copied out the pre-POST vbios from the idle card from console and inserted the rom into the xml using the Seabios or OVMF tags to correctly pass-through and alleviate the black screen issue (tech-powerup files wouldn’t work for me). I do this on all new test VMs since I sorted this issue out. I have also read that switching from VNC => to a dedicate GPU can cause issues sometimes. It also means I don’t have to deal with changing it later. Hyper-V is also turned off. To enable the MSI for Interrupts to Fix HDMI Audio Support I use the MSI_util located here. I quickly grew tired of manually adding the registry keys. http://lime-technology.com/forum/index.php?topic=47089.msg453707#msg453707 I have not made any modifications to the XML aside from inserting the vbios rom mentioned above. I have made no hardware modifications since the initial setup, so all tests have been performed on exactly the same hardware. Things I have not tried: I just realized that I have never used “qemu-ga-x64.msi” could this cause these sort of issues? I have never used machine Q35. I have always used i440fx. Might this help? Are the stable virtio-win-0.1.102 drivers new? I kind of remember version of it being something with a 9. So it may be possible that I’ve never tried this version of the “stable” drivers. After having written this all out. I think my next few steps will be… 1) Installing the qemu-ga-x64.msi from now on 2) Trying the stable 1.102 drivers. Will these even work with Win10? 3) Trying a VM as a Q35 machine 4) Rinse and repeat all of these options on 6.2 beta 20 again, if nothing works in 6.19. I will let you know how my tests go after I get home and try it out tonight. Until then though, does anyone have any other suggestions off the top of their heads? Thanks