stealth82 Posted December 21, 2015 Share Posted December 21, 2015 I don't even want to mention the huge amount of time I'm wasting down the toilet trying this new fancy virtualization but I'm very close to give up entirely. What I experienced so far is not what I had in mind. Is it possible that a VM can completely freeze and make unRAID go totally unresponsive for the second time in a few days?? Now a new parity check is waiting for me as soon as I hard reset the server. And I won't have any syslog to inspect in order to understand what went wrong again. This time it happened 20/30 mins after I started playing a movie and just like that the VM and and, what is worse, the server are dead. Link to comment
CHBMB Posted December 21, 2015 Share Posted December 21, 2015 I don't even want to mention the huge amount of time I'm wasting down the toilet trying this new fancy virtualization but I'm very close to give up entirely. What I experienced so far is not what I had in mind. Is it possible that a VM can completely freeze and make unRAID go totally unresponsive for the second time in a few days?? Now a new parity check is waiting for me as soon as I hard reset the server. And I won't have any syslog to inspect in order to understand what went wrong again. This time it happened 20/30 mins after I started playing a movie and just like that the VM and and, what is worse, the server are dead. Perhaps with a few more details on your config and hardware people may be able to offer some advice. There are a lot of us, me included, who are using a variety of virtual machines without issue. I've got Ubuntu, OSX, Win10 and Unraid all virtualised under an Unraid host with no problems at all. Link to comment
stealth82 Posted December 21, 2015 Author Share Posted December 21, 2015 MB: Intel DZ77SL-50K CPU: Intel® Core™ i5-3570T Memory: 8192 MB GeForce GTX 750 pass-thru AOC-SASLP-MV8 Asus Xonar ST 2 pass-thru Cache: Samsung EVO 850 btrfs Windows 10, SeaBIOS, 440fx 2.3, qcow2 Details 00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor DRAM Controller (rev 09) 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09) 00:02.0 VGA compatible controller: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor Graphics Controller (rev 09) 00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04) 00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04) 00:19.0 Ethernet controller: Intel Corporation 82579V Gigabit Network Connection (rev 04) 00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4) 00:1c.7 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 8 (rev c4) 00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 00:1f.0 ISA bridge: Intel Corporation Z77 Express Chipset LPC Controller (rev 04) 00:1f.2 SATA controller: Intel Corporation 7 Series/C210 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04) 00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04) 01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750] (rev a2) 01:00.1 Audio device: NVIDIA Corporation Device 0fbc (rev a1) 02:00.0 RAID bus controller: Marvell Technology Group Ltd. MV64460/64461/64462 System Controller, Revision B (rev 01) 03:00.0 PCI bridge: Integrated Technology Express, Inc. Device 8892 (rev 30) 04:00.0 Multimedia audio controller: C-Media Electronics Inc CMI8788 [Oxygen HD Audio] [0:0:0:0] disk SanDisk Cruzer Fit 1.22 /dev/sda [1:0:0:0] disk ATA WDC WD20EZRX-00D 0A80 /dev/sdd [1:0:1:0] disk ATA WDC WD20EARS-00M AB51 /dev/sde [1:0:2:0] disk ATA WDC WD20EARS-00M AB51 /dev/sdf [1:0:3:0] disk ATA SAMSUNG HD204UI 0001 /dev/sdg [1:0:4:0] disk ATA SAMSUNG HD204UI 0001 /dev/sdh [1:0:5:0] disk ATA Samsung SSD 850 1B6Q /dev/sdi [2:0:0:0] disk ATA ST2000DM001-1CH1 CC29 /dev/sdb [3:0:0:0] disk ATA TOSHIBA MD04ACA4 FP2A /dev/sdc vm settings <domain type='kvm' xmlns:qemu='http://libvirt.org/schemas/domain/qemu/1.0'> <name>HTPC</name> <uuid>03647809-f67f-a683-a756-9b1522e620f2</uuid> <description>Virtual Home Theater PC</description> <metadata> <vmtemplate name="Custom" icon="windows.png" os="windows"/> </metadata> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <memoryBacking> <nosharepages/> <locked/> </memoryBacking> <vcpu placement='static'>2</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='3'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-2.3'>hvm</type> </os> <features> <acpi/> <apic/> </features> <cpu mode='host-passthrough'> <topology sockets='1' cores='2' threads='1'/> </cpu> <clock offset='localtime'> <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/bin/qemu-system-x86_64</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='writeback'/> <source file='/mnt/cache/vm/htpc/vdisk1.qcow2'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/software/iso/SW_DVD5_WIN_ENT_10_64BIT_English_MLF_X20-26061.ISO'/> <target dev='hda' bus='ide'/> <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/software/iso/virtio-win-0.1.110.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' 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='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:cc:18:9c'/> <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='bind' path='/var/lib/libvirt/qemu/channel/target/HTPC.org.qemu.guest_agent.0'/> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <hostdev mode='subsystem' type='usb' managed='yes'> <source> <vendor id='0x046d'/> <product id='0xc52b'/> </source> </hostdev> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x04' slot='0x00' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x06' function='0x0'/> </hostdev> <memballoon model='virtio'> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </memballoon> </devices> <qemu:commandline> <qemu:arg value='-device'/> <qemu:arg value='ioh3420,bus=pci.0,addr=1c.0,multifunction=on,port=2,chassis=1,id=root.1'/> <qemu:arg value='-device'/> <qemu:arg value='vfio-pci,host=01:00.0,bus=root.1,addr=00.0,multifunction=on,x-vga=on'/> </qemu:commandline> </domain> My early posts: SSD cache disk throwing lots of errors: disk or cabling issue? I also have write performance issues, 25-30MB transfer speed between cache to/from array or array disk to/from array disk. If I'm lucky it is the supermicro controller possessing the whole server... Link to comment
saarg Posted December 21, 2015 Share Posted December 21, 2015 Did you get the cache disk errors fixed? Link to comment
stealth82 Posted December 21, 2015 Author Share Posted December 21, 2015 I'm still waiting for the cables, but I plugged the disk back to the mb controller, reformatted the disk to xfs and.... Dec 21 21:36:52 Tower emhttp: shcmd (203): set -o pipefail ; mkfs.xfs -m crc=1,finobt=1 -f /dev/sdb1 |& logger Dec 21 21:36:52 Tower kernel: ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x480100 action 0x6 frozen Dec 21 21:36:52 Tower kernel: ata1.00: irq_stat 0x08000000, interface fatal error Dec 21 21:36:52 Tower kernel: ata1: SError: { UnrecovData 10B8B Handshk } Dec 21 21:36:52 Tower kernel: ata1.00: failed command: DATA SET MANAGEMENT Dec 21 21:36:52 Tower kernel: ata1.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 16 dma 512 out Dec 21 21:36:52 Tower kernel: res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error) Dec 21 21:36:52 Tower kernel: ata1.00: status: { DRDY } Dec 21 21:36:52 Tower kernel: ata1: hard resetting link Dec 21 21:36:53 Tower kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: supports DRM functions and may not be fully accessible Dec 21 21:36:53 Tower kernel: ata1.00: failed to get NCQ Send/Recv Log Emask 0x1 Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: supports DRM functions and may not be fully accessible Dec 21 21:36:53 Tower kernel: ata1.00: failed to get NCQ Send/Recv Log Emask 0x1 Dec 21 21:36:53 Tower kernel: ata1.00: configured for UDMA/133 Dec 21 21:36:53 Tower kernel: ata1.00: device reported invalid CHS sector 0 Dec 21 21:36:53 Tower kernel: ata1: EH complete Dec 21 21:36:53 Tower kernel: ata1.00: exception Emask 0x10 SAct 0x0 SErr 0x400100 action 0x6 frozen Dec 21 21:36:53 Tower kernel: ata1.00: irq_stat 0x08000000, interface fatal error Dec 21 21:36:53 Tower kernel: ata1: SError: { UnrecovData Handshk } Dec 21 21:36:53 Tower kernel: ata1.00: failed command: DATA SET MANAGEMENT Dec 21 21:36:53 Tower kernel: ata1.00: cmd 06/01:01:00:00:00/00:00:00:00:00/a0 tag 5 dma 512 out Dec 21 21:36:53 Tower kernel: res 50/00:00:00:00:00/00:00:00:00:00/a0 Emask 0x10 (ATA bus error) Dec 21 21:36:53 Tower kernel: ata1.00: status: { DRDY } Dec 21 21:36:53 Tower kernel: ata1: hard resetting link Dec 21 21:36:53 Tower kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: supports DRM functions and may not be fully accessible Dec 21 21:36:53 Tower kernel: ata1.00: failed to get NCQ Send/Recv Log Emask 0x1 Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: supports DRM functions and may not be fully accessible Dec 21 21:36:53 Tower kernel: ata1.00: failed to get NCQ Send/Recv Log Emask 0x1 Dec 21 21:36:53 Tower kernel: ata1.00: configured for UDMA/133 Dec 21 21:36:53 Tower kernel: ata1.00: device reported invalid CHS sector 0 Dec 21 21:36:53 Tower kernel: ata1: EH complete Dec 21 21:36:53 Tower kernel: ata1.00: exception Emask 0x10 SAct 0x800 SErr 0x400100 action 0x6 frozen Dec 21 21:36:53 Tower kernel: ata1.00: irq_stat 0x08000000, interface fatal error Dec 21 21:36:53 Tower kernel: ata1: SError: { UnrecovData Handshk } Dec 21 21:36:53 Tower kernel: ata1.00: failed command: WRITE FPDMA QUEUED Dec 21 21:36:53 Tower kernel: ata1.00: cmd 61/00:58:40:00:00/01:00:00:00:00/40 tag 11 ncq 131072 out Dec 21 21:36:53 Tower kernel: res 40/00:58:40:00:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Dec 21 21:36:53 Tower kernel: ata1.00: status: { DRDY } Dec 21 21:36:53 Tower kernel: ata1: hard resetting link Dec 21 21:36:53 Tower kernel: ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: supports DRM functions and may not be fully accessible Dec 21 21:36:53 Tower kernel: ata1.00: failed to get NCQ Send/Recv Log Emask 0x1 Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Dec 21 21:36:53 Tower kernel: ata1.00: supports DRM functions and may not be fully accessible Dec 21 21:36:53 Tower kernel: ata1.00: failed to get NCQ Send/Recv Log Emask 0x1 Dec 21 21:36:53 Tower kernel: ata1.00: configured for UDMA/133 Dec 21 21:36:53 Tower kernel: ata1: EH complete Dec 21 21:36:53 Tower kernel: ata1: limiting SATA link speed to 3.0 Gbps Dec 21 21:36:53 Tower kernel: ata1.00: exception Emask 0x10 SAct 0x4000 SErr 0x400100 action 0x6 frozen Dec 21 21:36:53 Tower kernel: ata1.00: irq_stat 0x08000000, interface fatal error Dec 21 21:36:53 Tower kernel: ata1: SError: { UnrecovData Handshk } Dec 21 21:36:53 Tower kernel: ata1.00: failed command: WRITE FPDMA QUEUED Dec 21 21:36:53 Tower kernel: ata1.00: cmd 61/00:70:40:00:00/01:00:00:00:00/40 tag 14 ncq 131072 out Dec 21 21:36:53 Tower kernel: res 40/00:70:40:00:00/00:00:00:00:00/40 Emask 0x10 (ATA bus error) Dec 21 21:36:53 Tower kernel: ata1.00: status: { DRDY } Dec 21 21:36:53 Tower kernel: ata1: hard resetting link Dec 21 21:36:54 Tower kernel: ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 320) Dec 21 21:36:54 Tower kernel: ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Dec 21 21:36:54 Tower kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Dec 21 21:36:54 Tower kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Dec 21 21:36:54 Tower kernel: ata1.00: supports DRM functions and may not be fully accessible Dec 21 21:36:54 Tower kernel: ata1.00: failed to get NCQ Send/Recv Log Emask 0x1 Dec 21 21:36:54 Tower kernel: ata1.00: ACPI cmd ef/10:06:00:00:00:00 (SET FEATURES) succeeded Dec 21 21:36:54 Tower kernel: ata1.00: ACPI cmd f5/00:00:00:00:00:00 (SECURITY FREEZE LOCK) filtered out Dec 21 21:36:54 Tower kernel: ata1.00: ACPI cmd b1/c1:00:00:00:00:00 (DEVICE CONFIGURATION OVERLAY) filtered out Dec 21 21:36:54 Tower kernel: ata1.00: supports DRM functions and may not be fully accessible Dec 21 21:36:54 Tower kernel: ata1.00: failed to get NCQ Send/Recv Log Emask 0x1 Dec 21 21:36:54 Tower kernel: ata1.00: configured for UDMA/133 Dec 21 21:36:54 Tower kernel: ata1: EH complete Dec 21 21:36:54 Tower logger: meta-data=/dev/sdb1 isize=512 agcount=4, agsize=15262410 blks ... set the NCQ disabled to yes again - because I also noticed that makes unRAID throw errors like crazy and rsync'ed the data back, at the magical speed of 13MB/s (woot... just joking...) The VM is running at the moment, trying to "stress" it the same way I was doing earlier today. But theres's something hitching me. The SSD, although on a 6Gb channel port is operating at 3Gb... Link to comment
saarg Posted December 21, 2015 Share Posted December 21, 2015 I think your priority should be to fix the cache disk. When that is fixed you can go ahead and play with virtualization Link to comment
stealth82 Posted December 22, 2015 Author Share Posted December 22, 2015 Here, I think I nailed it https://bugzilla.kernel.org/show_bug.cgi?id=72341 Link to comment
stealth82 Posted December 22, 2015 Author Share Posted December 22, 2015 I think any Samsung 840/850 is not safe choice for unRAID, let alone for any Linux distribution... Link to comment
saarg Posted December 22, 2015 Share Posted December 22, 2015 I have 2 850 Evo and have no problems. Have you upgraded the firmware to the latest on yours? Link to comment
stealth82 Posted December 22, 2015 Author Share Posted December 22, 2015 I checked but there are no firmware upgrades for it. Yours might be a lucky hardware combination then, but I totally see the problem and I don't wanna deal with it any longer. Since I bought it a few weeks ago I'm still eligible to send it back and be refunded, I will buy a different disk and see what happens. Link to comment
saarg Posted December 22, 2015 Share Posted December 22, 2015 I'm not sure if you have the same problem as in the bug report you linked to. The only one with the same problem as you got his errors fixed after a BIOS upgrade. The error going through the bug report is mostly "failed to get NCQ Send/Recv Log Emask 0x1" and it didn't look like there was any data corruption. But I just skimmed through it as it was too long to read everything. Link to comment
stealth82 Posted December 26, 2015 Author Share Posted December 26, 2015 OK, the errors were definitely caused by my 4 too old sata cables. Bought new 6gb certified ones and the speed is finally 6gb stable. I'm using xfs and the result is... I'm counting the 5 complete freeze since I started tinkering with virtualization. Next step will be removing the audio card and watching movies in complete silence. I still believe that the complete freeze of unRAID is simply UNACCEPTABLE. Link to comment
beire Posted December 27, 2015 Share Posted December 27, 2015 I too can confirm it's very well possible of crashing unraid with virtualization. Had it happen a couple times to me as well. Always happened with gpu pass through. My thoughts are gpu pass through is still a bit too young. I have since reinstated my htpc hardware but moved it to my rack underneath my unraid hardware. Link to comment
jonp Posted December 27, 2015 Share Posted December 27, 2015 I too can confirm it's very well possible of crashing unraid with virtualization. Had it happen a couple times to me as well. Always happened with gpu pass through. My thoughts are gpu pass through is still a bit too young. I have since reinstated my htpc hardware but moved it to my rack underneath my unraid hardware. While I can appreciate that some folks are going to have issues with certain hardware, I can assure everyone that those issues are indeed hardware issues. With good hardware, the crashing issues you're seeing will go away. There are many in the forum that have had great success, so writing off the entire tech/solution due to a few bad apples just doesn't make sense to me. What I will agree with is that we are not at the stage of "use absolutely any hardware you want" yet. Motherboard, CPU, and GPU all matter and in a big way. This is continuing to get better with further software updates and hardware improvements as well. Link to comment
JonathanM Posted December 27, 2015 Share Posted December 27, 2015 Motherboard, CPU, and GPU all matter and in a big way. This is continuing to get better with further software updates and hardware improvements as well. Is there a list being maintained of what works well? It would be nice to be able to choose components that are known to work. Link to comment
beire Posted December 27, 2015 Share Posted December 27, 2015 I too can confirm it's very well possible of crashing unraid with virtualization. Had it happen a couple times to me as well. Always happened with gpu pass through. My thoughts are gpu pass through is still a bit too young. I have since reinstated my htpc hardware but moved it to my rack underneath my unraid hardware. While I can appreciate that some folks are going to have issues with certain hardware, I can assure everyone that those issues are indeed hardware issues. With good hardware, the crashing issues you're seeing will go away. There are many in the forum that have had great success, so writing off the entire tech/solution due to a few bad apples just doesn't make sense to me. What I will agree with is that we are not at the stage of "use absolutely any hardware you want" yet. Motherboard, CPU, and GPU all matter and in a big way. This is continuing to get better with further software updates and hardware improvements as well. Hey Jon, My reply was not meant to be negative to the work you and the team have done to unraid and its vm capabilities. Coming from esxi I realise what a pain in the *** gpu pass through can be. My setup was working way better than it ever did on esxi, but I just think it's still better to wait a bit longer. At least for me. Link to comment
stealth82 Posted December 28, 2015 Author Share Posted December 28, 2015 so writing off the entire tech/solution due to a few bad apples just doesn't make sense to me. If I may say, that would depend on the importance of what else is running on the machine hosting it. The concept on the paper is good but if the catch is "with unholy hardware it may cause a heck of a complete freeze and say bye to unRAID and welcome to parity check" I would think twice before even thinking whether I want to endanger my data for the fun of it. I get it's not unRAID's fault, I guess complete "isolation" isn't achievable (yet?), but how can that be good for the product? It is nice but I can't say it is wise. If only good tested configs are allowed then this must be stated, and all the untested ones get the "experimental/run at your risk" label right where it's necessary to see it. I'm saying these things only because unRAID is freezing. I couldn't care less if it were just the VM to freeze. Link to comment
jonp Posted December 28, 2015 Share Posted December 28, 2015 so writing off the entire tech/solution due to a few bad apples just doesn't make sense to me. If I may say, that would depend on the importance of what else is running on the machine hosting it. The concept on the paper is good but if the catch is "with unholy hardware it may cause a heck of a complete freeze and say bye to unRAID and welcome to parity check" I would think twice before even thinking whether I want to endanger my data for the fun of it. I get it's not unRAID's fault, I guess complete "isolation" isn't achievable (yet?), but how can that be good for the product? It is nice but I can't say it is wise. If only good tested configs are allowed then this must be stated, and all the untested ones get the "experimental/run at your risk" label right where it's necessary to see it. I'm saying these things only because unRAID is freezing. I couldn't care less if it were just the VM to freeze. That's why we encourage testing first. You can see if your hardware works solid before committing gobs and gobs of critical data to it. That said, if you are holding critical data and have no other backups, then you probably shouldn't be testing anything on that system. Link to comment
stealth82 Posted December 28, 2015 Author Share Posted December 28, 2015 If that had been possible I would surely have done it. I certainly have backups of what is vital but, still, running the parity check is mandatory and a PITA. It would already be something if one could just try out the VM without having to start the array. In that case, if the server froze, the data would still be safe and sound after the restart. Link to comment
bungee91 Posted December 28, 2015 Share Posted December 28, 2015 Some GPU's (mainly), and other devices don't work too well and can cause lag, and instability issues. This can be seen with lockups to the entire server when rebooting the VM, sometimes with driver installation, and also a fresh boot up of the VM after previously being powered on/off. Since I in no way work for L.T. my comments may be a bit more helpful (or at least seen as not trying to sell you on something). Many user's have success with the right components, and a LOT of them work. I have done extensive testing with a Z87, a Z97, and now an X99 setup. I have no server stability issues running 4 VM's continuously (typing on 1 now), 3 with GPU passthrough (also a USB controller, sound card). The GPU's I have had great success (in everything I can throw at them) is the GT720's (I have 3 installed), and an R7_260X (my main "Rig"). I have gone as far as selling my old main computer, and only use VM's hosted by UnRaid, and I've got to say it works damn well! I have had issues (and wanted to pull my hair out and scream at the world) with a G210, and 5450 video cards. Both would lock up the server completely, it was extremely frustrating! Once I tested a 720 and realized that JonP wasn't lying to me then I was hooked! Now with proper isolation on processor root ports (woot "Extreme" Core processor!), I am extremely pleased. Link to comment
Recommended Posts
Archived
This topic is now archived and is closed to further replies.