breakline Posted February 28, 2015 Share Posted February 28, 2015 Trying to figure out why it does this and how to fix it or if I am doing something wrong . Long story short : every time I install windows via kvm (many times already) windows is very slow and task manager shows %100 disk . This is my test server so I've reformatted all disks and flash and re-install unraid and same issue , all latest versions. my setup : unraid versions 6b12-14b motherboard : ASRock Fatal1ty 990FX Killer, with IOMMU enabled cpu: fx8350 ram:16GB trident x ddr3 2400 passthrough gpu:msi 660 twin frozr for passthrough unraid gpu: geforce 210 windows 8.1 and windows 10 both with msi 660 twin frozr for passthrough q35 4 vCPU and 8192 (8gb) RAM for both I tried adding this with no improvement: <driver name='qemu' type='qcow2' cache='none' io='native'/> after passthrough it does not seem as bad but still very sluggish. here's my xml's before and after tweaks/passthrough untouched xml: <domain type='kvm'> <name>windows 10</name> <uuid>f564e480-bfca-7981-ec4c-8f74268ec9cf</uuid> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <vcpu placement='static'>4</vcpu> <os> <type arch='x86_64' machine='pc-q35-2.1'>hvm</type> <boot dev='hd'/> </os> <features> <acpi/> <apic/> </features> <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/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <source file='/mnt/cache/kvm/vms/windows 10/windows 10.qcow2'/> <target dev='hda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/cache/kvm/isos/Windows10_TechnicalPreview_x64_EN-US_9926.iso'/> <target dev='hdc' bus='sata'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:26:b0:57'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <graphics type='vnc' port='-1' autoport='yes' websocket='-1' listen='0.0.0.0'> <listen type='address' address='0.0.0.0'/> </graphics> <video> <model type='vmvga' vram='16384' heads='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/> </video> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </memballoon> </devices> </domain> and here's my xml with tweaks and passthrough: <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>windows 10</name> <uuid>f564e480-bfca-7981-ec4c-8f74268ec9cf</uuid> <memory unit='KiB'>8388608</memory> <currentMemory unit='KiB'>8388608</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>4</vcpu> <cputune> <vcpupin vcpu='0' cpuset='0'/> <vcpupin vcpu='1' cpuset='1'/> <vcpupin vcpu='2' cpuset='2'/> <vcpupin vcpu='3' cpuset='3'/> </cputune> <os> <type arch='x86_64' machine='pc-q35-2.1'>hvm</type> <boot dev='cdrom'/> <bootmenu enable='no'/> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough'> <topology sockets='2' cores='2' threads='1'/> </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/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none' io='native'/> <source file='/mnt/cache/kvm/vms/windows 10/windows 10.qcow2'/> <target dev='hda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x03' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/cache/kvm/isos/Windows10_TechnicalPreview_x64_EN-US_9926.iso'/> <target dev='hdc' bus='sata'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='2'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='sata' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/> </controller> <controller type='pci' index='0' model='pcie-root'/> <controller type='pci' index='1' model='dmi-to-pci-bridge'> <address type='pci' domain='0x0000' bus='0x00' slot='0x1e' function='0x0'/> </controller> <controller type='pci' index='2' model='pci-bridge'> <address type='pci' domain='0x0000' bus='0x01' slot='0x01' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:26:b0:57'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x02' slot='0x01' function='0x0'/> </interface> <serial type='pty'> <target port='0'/> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <input type='tablet' bus='usb'/> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x02' slot='0x04' function='0x0'/> </memballoon> </devices> <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pcie.0,addr=1c.0,multifunction=on,port=1,chassis=1,id=root.1'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=04:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=04:00.1,bus=pcie.0'/> </qemu:commandline> </domain> not really sure where to go from here so any input would be appreciated. Quote Link to comment
jonp Posted February 28, 2015 Share Posted February 28, 2015 Windows does lots of background tasks to index files when you're idle. In addition, page file activity can impact performance as well. I found that disabling indexing and, if you have enough RAM, the page file, you will see disk activity drop. I've seen the same behavior with windows 8.1 / 10 on a physical desktop. Another thing is that you are passing through an NVIDIA GPU. If you revert to driver 340.52, you can add the hyper v extensions into the xml beyond just the timer. I will share the xml for that tomorrow, or you can look at the libvirt documentation for domain xml format and you'll find it in there as well. Things like vapic and spinlocks should improve things. Quote Link to comment
breakline Posted February 28, 2015 Author Share Posted February 28, 2015 jonp thank you for the quick reply , and yeah I have seen that on a lot of 8.1 machines as well and usually found it to be the windows antimalware service if I remember correctly. Thank you for the info , I'll try those suggestions and look into the libvirt docs and post back. EDIT: ok so i have not checked out the libvirt docs yet but disabling index made a huge improvement so far and made windows useable ,also disabled page file but i dont know how much improvement that made yet. Thank You will post more upon trying your other suggestions Quote Link to comment
jonp Posted March 1, 2015 Share Posted March 1, 2015 jonp thank you for the quick reply , and yeah I have seen that on a lot of 8.1 machines as well and usually found it to be the windows antimalware service if I remember correctly. Thank you for the info , I'll try those suggestions and look into the libvirt docs and post back. EDIT: ok so i have not checked out the libvirt docs yet but disabling index made a huge improvement so far and made windows useable ,also disabled page file but i dont know how much improvement that made yet. Thank You will post more upon trying your other suggestions Glad you're seeing an improvement. As I mentioned, here is the additional code you can place in your XML file between the <features> and </features> tag to optimize KVM for a Windows guest: <viridian/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> </hyperv> NOTE: NVIDIA has code to detect the presence of this in driver versions > 340.52. If using a newer driver, it will disable the GPU with a code 43 error with these hyper-v tags on. Quote Link to comment
archedraft Posted March 4, 2015 Share Posted March 4, 2015 <viridian/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> </hyperv> NOTE: NVIDIA has code to detect the presence of this in driver versions > 340.52. If using a newer driver, it will disable the GPU with a code 43 error with these hyper-v tags on. What are the benefits of using hyper-v? Quote Link to comment
jonp Posted March 4, 2015 Share Posted March 4, 2015 <viridian/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> </hyperv> NOTE: NVIDIA has code to detect the presence of this in driver versions > 340.52. If using a newer driver, it will disable the GPU with a code 43 error with these hyper-v tags on. What are the benefits of using hyper-v? Hyper v extensions make Windows "aware" that it is being run as a virtual machine, which cab improve performance a bit, but to be totally honest, I'm not sure how much of an impact this has on certain use cases like gaming. Quote Link to comment
archedraft Posted March 4, 2015 Share Posted March 4, 2015 What are the benefits of using hyper-v? Hyper v extensions make Windows "aware" that it is being run as a virtual machine, which cab improve performance a bit, but to be totally honest, I'm not sure how much of an impact this has on certain use cases like gaming. Well I will give it a shot then and see whats happens. Why would Nvidia care if the system knows its a VM or not? Quote Link to comment
jonp Posted March 4, 2015 Share Posted March 4, 2015 What are the benefits of using hyper-v? Hyper v extensions make Windows "aware" that it is being run as a virtual machine, which cab improve performance a bit, but to be totally honest, I'm not sure how much of an impact this has on certain use cases like gaming. Well I will give it a shot then and see whats happens. Why would Nvidia care if the system knows its a VM or not? So there is what is being officially stated by nVIDIA, and then there's what you can "read between the lines" on. The official statement is that this is a "bug" but that it won't be solved because assigning a consumer-grade GPU to a VM is not officially supported. The reason this is a fishy sounding answer is because originally, the cards worked fine and no tom-foolery was needed to make them work. Then they started detecting the KVM flag that is exposed through MSRs to the guest OS and if found, would render a Code 43 error in windows, making the device unusable for 3d graphics. The KVM/QEMU/libvirt team saw this and implemented a simple mechanism to just hide that flag and when done, Code 43 error would go away. Then a few weeks later, after another driver update, Code 43 errors would come back even with this flag hidden. So then the same guys that fixed it the first time around figured out that this new driver update was now detecting the presence of hyper-v extensions in Windows and again, rendered the card unusable with another Code 43 error. Removing the hyper-v flags solves the issue. The primary theory as to why (and again, this is only a theory), is that nVIDIA doesn't want people to be able to take consumer-grade cards and virtualize with them. They want folks to purchase their high-end server-grade cards for this, which is ludicrous as they cost a fortune. What nVIDIA needs to realize is that there are two use cases for GPUs with virtualization. The corporate use case is to put a single GPU (or maybe a few via SLI) into a system, but allocate it to multiple virtual machines concurrently (their server grade cards support this). What this does it makes it possible to run 3D graphics applications on a virtual desktop, then stream them to users over a thin remote graphics protocol like Citrix ICA or Microsoft RDP w/ RemoteFX. The consumer use-case is NOT to do that, but rather, output video using HDMI / VGA / DVI / whatever from the card directly to a monitor, where the relationship between GPUs and VMs is at a 1:1 ratio. Only time will tell if they will wake up and smell the coffee on this. Maybe AMD will catch wind and see this as an opportunity for them to shine. Quote Link to comment
GHunter Posted March 6, 2015 Share Posted March 6, 2015 Glad you're seeing an improvement. As I mentioned, here is the additional code you can place in your XML file between the <features> and </features> tag to optimize KVM for a Windows guest: <viridian/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> </hyperv> NOTE: NVIDIA has code to detect the presence of this in driver versions > 340.52. If using a newer driver, it will disable the GPU with a code 43 error with these hyper-v tags on. I also noticed some problems in the <clock /> node in the XML while experimenting tonight. <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> With a Windows 7 and a Windows 10 VM, if either of those <timer /> lines were in my XML, the latest Nvidia drivers would not install correctly. Without modifying the XML for either of the VM's, I could install Nvidia driver version 340.52 without any issue or errors. Once I removed the 2 <timer /> lines like so: <clock offset='localtime'> </clock> I was then able to install the latest Nvidia drivers without any issues in both VM's and they seem to be running just fine. One issue I have left to play with in regards to Nvidia drivers is the CPU that is being reported to Windows and the Nvidia Gaming Experience. The CPU is being reported as an QEMU Virtual CPU Version 2.2.0 3.60 GHz. I am pretty sure I read somewhere on the libvirt website that you can change how the CPU is reported to the guest OS. Hope this info is helpful for those experiencing driver install problems. Edit: Here is the link on CPU model information. http://libvirt.org/formatdomain.html#elementsCPU Gary Quote Link to comment
jonp Posted March 6, 2015 Share Posted March 6, 2015 Glad you're seeing an improvement. As I mentioned, here is the additional code you can place in your XML file between the <features> and </features> tag to optimize KVM for a Windows guest: <viridian/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> </hyperv> NOTE: NVIDIA has code to detect the presence of this in driver versions > 340.52. If using a newer driver, it will disable the GPU with a code 43 error with these hyper-v tags on. I also noticed some problems in the <clock /> node in the XML while experimenting tonight. <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> With a Windows 7 and a Windows 10 VM, if either of those <timer /> lines were in my XML, the latest Nvidia drivers would not install correctly. Without modifying the XML for either of the VM's, I could install Nvidia driver version 340.52 without any issue or errors. Once I removed the 2 <timer /> lines like so: <clock offset='localtime'> </clock> I was then able to install the latest Nvidia drivers without any issues in both VM's and they seem to be running just fine. One issue I have left to play with in regards to Nvidia drivers is the CPU that is being reported to Windows and the Nvidia Gaming Experience. The CPU is being reported as an QEMU Virtual CPU Version 2.2.0 3.60 GHz. I am pretty sure I read somewhere on the libvirt website that you can change how the CPU is reported to the guest OS. Hope this info is helpful for those experiencing driver install problems. Edit: Here is the link on CPU model information. http://libvirt.org/formatdomain.html#elementsCPU Gary Ok, I think you could put those lines back if you set your CPU mode to host-passthrough. There are other posts from me on how to do that, but I will repost later. Quote Link to comment
GHunter Posted March 6, 2015 Share Posted March 6, 2015 Hmm, I'll boot into unRaid w/ KVM and post my whole XML file. It was generated from using the VM Manager plugin, then I made edits for GPU and USB passthrough. It was quick and easy to do and I had fun playing with it. My previous attempts with passthrough in the beta 11 and 12 time frame resulted in BSOD's and I tried a number of XML examples that you and others had posted. So I figured I'd wait a bit. I have a feeling it was due to the VirtIO drivers I was using at the time. Also, I'm not saying that those <timer /> lines are being detected by Nvidia, just that the new drivers wouldn't install correctly which showed up in Windows device manager with the yellow exclamation point. I wanted to try another driver and since you mentioned v340.52 resolved the Nvidia flag problem, I figured that version would be good for me to try. I'll start a new thread for this. This one is getting off topic. Sorry Gary 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.