testdasi

Cadvisor?

+1

Attach Diagnostics.

Q35 machine. Do you have this section of code in the xml, before </domain>? If not, add it. Otherwise your GPU runs at PCIe x1. <qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.speed=8'/> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.width=16'/> </qemu:commandline>

What do you mean by not showing up on the ui?

It usually will be plug-and-play. There are some controllers out there that truncates the serial number, then you will need to readd. You can ask around on the forum for recommendations.

That's your problem for insisting on using Krusader then. I told you what's wrong with it (and that is a generic problem regardless of file type). Personally I don't see what's so hard about using CA Users Script -> create new script -> put this line in the script cp -rv /mnt/diskX/* /mnt/diskY/ -> Save -> Run in Background -> Go have a beer Also I don't think you are right about those container files. Unless you mount them, the file system exposes it to Krusader (or any other tool) as a single file. Krusader won't even attempt to mount such image to read what is underneath to move the files within. Any competent coder knows it is extremely silly to do so and I trust that Krusader coders are competent. PS: you asked a similar question 1.5 years ago.

Are you doing the 3 disks in parallel or in sequence? And are you seeing the same slow down if doing cp (or mv) from console? I have found Krusader to be terrible for large file moves. It starts at normal speed but it grinds to an excruciating halt after some hours. It also creates many fragmentation patches, which cp / mv doesn't do. So maybe you should try doing it with cp / mv instead. And I don't think your proposal will at all help with transfer speed. The reason it's slow is because small files are inherently slower to read and write due to latency. Introducing compression the middle isn't going to save you time because you still have to read those same files from the old disk and write those same files to the new disk. If anything it will take even more time because you lose the smoothing effect of ram cache.

I think Unraid defaulting to i440fx is a legacy thing because Q35 used to be rubbish with Windows some years ago with the old qemu. From Unraid 6.6 onwards though, the progress made in qemu was good enough to make Q35 at least on par with i440fx and potentially even superior with regards to PCIe passthrough. I remember seeing posts in forum about some GPU that would not passthrough without Q35. A few tips for you: Q35 doesn't like SeaBIOS + Windows. So make sure you are on OVMF i.e. boot UEFI before switching. Start a new template. I think the i440fx pci -> Q35 pcie move is way too complicated for the Unraid GUI to handle. Don't forget that last bit of code to add manually to the xml. Wasted me an hour wondering why the F my 1070 doesn't work. <qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.speed=8'/> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.width=16'/> </qemu:commandline>

About 25TB. Took me 10 days, 2 of which on 150Mbps, 3 on 250Mbps (because my old router can't handle gigabit) and the rest on 1Gbps. Average speed is about 30MB/s but given 2/3 of the object counts are my offsite backup which are full of tiny files in the KB range, that's not too shabby. Compare that with Crashplan which last took 10 days to backup 200GB worth of files in the MB ranges and I'd say it's a huge improvement.

Oh dear. My prayers for you and your family, mate.

And trust that the people on your network doesn't do silly things, like accidentally exposing your server to the Internet, that sort of silly.

Hi Max. I suggest you post a request in the feature request forum. Not saying that LT will implement that but there's a better chance than posting in this old topic.

It depends on how many years and what games. Some games indeed don't play game with RDP (#BadPun). Some are unplayable (think 30fps with CS:GO, that sort of unplayable). So YMMV basically. That's why I recommended the OP to try it out as a proof of concept first.

Simpler solution. Try updating right after a reboot?

It's a Linux kernel problem. People are already trying to help to find workarounds but if it's not fixed in the kernel, there is no guarantee whatsoever that these workarounds would work for everyone. Don't blame the tires when the engine breaks. You can't possibly expect everyone on the forum to drop everything to give you (free) bespoke advice on an on-demand basis. Such expectation is also not acceptable. Best course of action for you is to use the last Unraid version that works.

Everything hangs when a disk is spinning up - that's to be expected. A disk refusing to spin up doesn't sound like a UD problem. My HDD spins up fine when accessed.

Some major updates: Many thanks to @DZMM for helping me with rclone. Rclone has allowed me to move most of my content up to the cloud, run parity less (better speed) and reduce my local storage needs (got rid of the 8TB Archive and 6TB Black - may get rid of the 8TB Iron Wolf in the future - my array now only serves as local backup and offline storage for some short-term content in case the Internet is down.). Plex works perfectly fine with cloud storage, even on my old 150/150 connection. Nobody in the household noticed my move to the cloud. It was that transparent. I won't tell anyone and see how long it takes for someone to notice. My upgrade to 1Gb/1Gb is more of a quality of life addition since I can do my offsite backup to the cloud more quickly. Will get rid of Crashplan as my offsite backup service. While they were great in the past, their recent move to business-only has exposed their shortcomings vs other business-level solutions. Speed and ease of restoration are the 2 biggest sore thumbs. My workstation VM is "upgraded" from i440fx to Q35. I'm delighted to announce, the GPU fans no longer stop while idling without MSI Afterburner! That means my PM983 can idle under 45 degrees regularly. I think once Unraid moves on to a more recent qemu, the default Win10 template should use Q35, which has better support for PCIe. At the moment, I have to manually add the codes below to the xml; otherwise, my PCIe runs at x1. <qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.speed=8'/> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.width=16'/> </qemu:commandline> The latest Linux kernel + F12 BIOS seem to make disabling Global C State Control less stable. For extremely strange reasons, that manifests as out of memory errors if I try to reserve more than 50% of RAM all at once (e.g. start my workstation VM). So if you disabled Global C State Control in the past and now seem to have some instability, maybe try enabling that with the latest BIOS.

How? Basically just "plug-and-play" albeit wirelessly. RDP is essentially just a glorified live screen capture software. The acceleration is between the game and the GPU. The GPU creates an output display. That display is normally out to the monitor. RDP captures that display and send it to you over the network (which explains the latency). Different streaming softwares differ by where and how they capture the output from the GPU. You can even try it for yourself (there are several free solutions out there, even open-source I think) with your current workstation. No need to commit to Unraid before you have a proof of concept.

Up from 6.7.1. No issue to report. Even my dual NIC doesn't have the same DNS problem.

When I was testing out various configs, I simply use User Scripts and do a simple cp to create a copy. I reckon someone more verse in shell script can sure create a folder based on time and cron it every hour or something.

That sounds like network problem. Install the Tips and Tweaks plugin and try disabling NIC Flow Control and/or NIC Offload to see if it helps.

Create a separate topic with a proper report of your problem and attach diagnostics. Posting a 3-line complaint on every release topic will not get you the necessary help.

When you transfer 1 single very large file (pick you 70GB mkv for example), what speed do you get? Does it flat line or fluctuate?

It very much depends on how AMC detects a VM. It's very much trial-and-error to see what works. 1. Unraid Windows 10 template already uses cpu passthrough so that should be transparent to the OS. 2. Try adding this code right above </features> <kvm> <hidden state='on'/> </kvm> 3. You might want to try both with Hyper-V and without (create new template for each). 4. The default Windows 10 template uses i440fx which is super old (1996!) so potentially is a red flag (nobody runs modern AMC on that sort of hard-ware). So maybe try switching to Q35. Remember to add this right above </domain> (otherwise your PCIe will be running at x1) <qemu:commandline> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.speed=8'/> <qemu:arg value='-global'/> <qemu:arg value='pcie-root-port.width=16'/> </qemu:commandline> 5. While you are at it, try both SeaBIOS and OVMF. Now if AMC blacklists QEMU manufacturer and/or Seabios + OVMF + Q35 + i440fx then you are SOL.