phbigred

That makes a lot of sense Squid!!! Moderator note: this was a response believed to be in reference to this post. It was moved to this Feedback thread, because we want to keep the FAQ clean, all feedback over here instead.

Be sure to post diagnostics too. Gives more detail of your setup.

Exactly this... It is to protect your data on cache.

I'd recommend using CrashPlan on the source and destination box as a docker. If you want a fast initial sync have your friend bring it to your house for the initial if there is a lot of data. 200Mb fiber can't beat 1Gb copper. Then link them together through crashplan.

Dumb question do both parity drives have to be the same size or just as big as the largest array drive?

Diagnostics can be grabbed by the webui under tools or from command line by typing diagnostics.

What you are hoping to do is exactly what I did with my rig. Why run 2 boxes when you can do the same sort of thing with one. Haven't looked back! Best recommendation I can give you, back up often and run it on a SSD cache drive. I have a plex docker and mcebuddy in the VM scrubbing my recordings with multi streams and gpu transcoding. Best thing is my unraid for the most part is spun down thanks to drive spin down options in drive settings except for my SSD cache drive.

Get Squid's community app plugin. Once installed you'll get a apps tab. Snag from there for dockers. There is a native docker for lime tech but this will give you more options. Under settings turn on docker then work forward. https://lime-technology.com/forum/index.php?topic=40262.0

Also for the cache pool, see if your shares are set to use cache or to prefer cache. I filled up mine accidentally with having preferred on.

When my vm pathing changed with the version upgrade from 6.19 to 6.2 I ran into something similar. I think it has something to do with not finding the image. Verify your disk.img location as it may have changed. Mine went originally in a VM folder on my array then with the upgrade it defaulted back to cache.

Totally would buy a set of two pint glasses. Maybe more for my friends that I'm converting from hardware RAID.

Try dropping your CPU count in case when the system was turned off it was installing a page update.

Reboot in safe mode and see if the issue still occurs. If it does it "may" be your browser.

Disk info you listed looks fine. Can you replace your data cable and or controller you are plugged into? Pulling a diagnostic will help assuming you haven't rebooted the array.

+1 rebuild the VM template. Just have it point manually to the vdisk you originally assigned. If there is concern just create a new one and use your original settings as a reference.

Did you install the Win 10 anniversary update? There's issues with bugs if you let it update automatically. Do a reinstall from windows 10 anniversary ISO you can get from MS. Once I did this all my disk and hangs corrected. It may require you to reset the entire VM as there may be settings that "hang". If you reset inside Windows make sure you set the CPU count to 1 as there's a bug with KVM and the reset process.

Can we safely assume you are talking about the GPU is passed through and when you turn off the VM it goes black? If that's the case you have 2 options at current: 1. Drop in another cheap GPU in slot 1 just for unraid. (What I do, and I change inputs on my monitor as I have an FX AMD) 2. Live with it until they possibly get a toggle sequence for the keyboard to go back to unraid. (I am not sure that is even on the roadmap)

Eric- That line worked for removing my alerts however there is a new line at the bottom. warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 4] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 5] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 6] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 7] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 8] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 9] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 12] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 13] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 14] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 15] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 16] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 17] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 23] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 24] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 0] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 1] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 2] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 3] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 4] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 5] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 6] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 7] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 8] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 9] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 12] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 13] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 14] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 15] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 16] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 17] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 23] warning: host doesn't support requested feature: CPUID.80000001H:EDX [bit 24] 2016-09-16T04:47:11.244188Z qemu-system-x86_64: terminating on signal 15 from pid 14088 2016-09-16 04:47:11.444+0000: shutting down 2016-09-16 05:16:11.002+0000: shutting down 2016-09-16 05:16:34.647+0000: starting up libvirt version: 1.3.1, qemu version: 2.5.1, hostname: unraid-box 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 Opteron_G3,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/9bf012c2-69c5-23b0-a41b-03e527487d8f_VARS-pure-efi.fd,if=pflash,format=raw,unit=1 -m 8192 -realtime mlock=on -smp 4,sockets=1,cores=2,threads=2 -uuid 9bf012c2-69c5-23b0-a41b-03e527487d8f -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 virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x3 -drive file=/mnt/cache/VMs/win10/vdisk1.img,format=ddr=0x8 -msg timestamp=on Domain id=3 is tainted: high-privileges char device redirected to /dev/pts/0 (label charserial0) 2016-09-16T05:16:34.755084Z qemu-system-x86_64: AMD CPU doesn't support hyperthreading. Please configure -smp options properly.

+1 turn off direct play in the client! I've run into many times where that is the bottleneck. Your HTPC is attempting to read the file directly and if it doesn't have the correct transcoders loaded into the os or hardware decoding it can have an issue. It's typically under Settings>advanced>video.

Might be worth doing a new config. Just keep track of which one is your parity.

Have you tried starting it without pass through? I have and 8350 with a gigabyte 970 mb passing through just fine. Also just to be clear if using an fx line chip you need another video card in one of the slots for passthrough. I use a cheap and card and have my 970 in a x16 8x slot. I don't have experience with the Apu chips but assigning the onboard video in bios for onboard by default could help. With one working and one not triple check your passthrough settings. Both can't run off the same card at the same time. I did have a "bug" with my cheap card passing as an option on an earlier version. Best practice is to not run the VM off the same card feeding the unraid display.

Use crashplan free. Use the unraid as a target. I have my family pcs backing up. Just route port 4241 an 4242 NAT to the Internet. It uses encryption that is sarbanes oxley compliant. Best route and free! There's a docker for it, put it to a share separate from the rest of your data and map the docker and shut off the share access for all users. It'll give you version retrieval. Great for recovery should you get a ransomware event and it is segregated. Also should you have a prob and have to rebuild you can adopt and restore. You can also retrieve data for another backup target. I've used it for seeding data to an external drive that I shipped to a family member across the country for an off-site backup solution for my critical data. On the question of port forwarding the OS level is always going to be the most attacked. Port forwarding is essentially popping holes in for an attacker from the outside. That's one of the main drivers why people are against it. If you pop open a hole someone will try to exploit it. It's the nature of the environment of the Internet. Wall yourself off as much as possible, if you make choices to do this understand the risks. If you can live with it, great, if not don't. It's a know your enemy sort of thing.

Owncloud makes a security key automatically when it builds. The encryption is 4096 bit so you "should" be fine. Here's more answers to that question. https://owncloud.org/faq/#protocol

If you aren't using a sftp connection any other type can be considered "plain-text" and is very insecure. VPN is the safest route that way it's a point to point connection and encrypted in-between. I don't allow anything outside my dockers, even then it is limited. I'd say if you need access outside to your shares plan ahead and drop stuff in your owncloud beforehand or vpn in and drop stuff in there as needed then when back inside your lan move stuff around off the owncloud.

I'm waiting for a new parity drive so this is a great "refresher" for me. The wiki is pretty straight forward but barring images or a YouTube vid imbedded in the wiki I think the wording change is beneficial.