testdasi

Tools -> Diagnostics -> attach zip file. Also, did you turn on SMT in the BIOS?

You either set up your vdisk as SATA previously (which should not need virtio driver) or you indeed installed the drivers from the iso.

Did you install the virtio drivers?

Only these things that come to mind: Isolate 24 cores to cover the full dies to spread the load evenly (20 cores will not spread evenly across die since there are 3 CCX per die). Something like 12 - 23 and 36 - 47. You may even get better performance cutting it down to 12 cores. Fewer cores may lead to more consistent performance. Take out all the cache + feature tuning in <cpu>, especially the cache. L3 cache should work correctly with Q35 4.x and does not need emulation (emulated L3 cache is unlikely to improve performance). The feature stuff was originally required as CPU was being emulated as EPYC instead of TR. Take out <timer name='hpet' present='no'/> because you already have present=yes. Add this <frequencies state='on'/> above </hyperv> Install Tips and Tweaks plugin and change your CPU governor to High Performance. Pass through the USB controller instead of attaching USB devices. The libvirt usb sometimes cause lags under load.

Run this first before doing the lstopo command: ln -s /lib64/libudev.so.1 /lib64/libudev.so.0

This probably relates to the recent Samba update that changed quite a bit with regards to security. I also noticed permission changes. I don't think there's much that can be done. If you need the insecure workaround then you probably have no choice but to stay on an earlier version that the workaround still worked. Otherwise you need to rethink the workaround.

Assume it won't work. Thunderbolt is at a very early stage in terms of support. I think driver was only added on 6.8.1-rc1 i.e. a few days ago.

Watch and follow the vid below to create the lstopo png image and attach it. Tools -> Diagnostics -> attach zip file. Hopefully it gives a better idea of what needs to be tuned. Also, did you isolate the cores for the VM?

Not impressed with what?

Perhaps before complicating the matter with running FlexRAID in a Windows VM (which is rather complicated since you can't pass through the HBA to the VM due to Unraid needing it to access the JBOD), have you tried just loading Unraid + Unassigned Devices plugin to see if it can actually mount the FlexRAID drives individually? Then if the drives can be mounted, perhaps copy a few of those files over to see if they are valid files. I vaguely remember FlexRAID to be what Daedalus said (i.e. each disk has its own file system) but it has been too long. Also, you can use Trial license to test it out before purchasing. Since your migration process is rather massive, I'm sure the LT guys will be understanding enough to give you an extension to the Trial so you can test the process out properly.

I bet a beer the answer is Soon™. 😅

I have a working mergefs mount but it just isn't used by anything. I don't do torrent nor hardlink so no benefit there My mount performance is bottlenecked by rclone and not unionfs so no performance benefit either I consider unionfs COW as a protection layer against cryptovirus (and accidental changes). A silent infection + COW would cause my local UD drive to fill up inexplicably which would alert me that something is amiss. So unless I'm missing something, there isn't anything that motivates me to fully switch at the moment.

If strictly just for storage (i.e. no Plex, VM etc.) then you don't even need cache drive. A cheapo CPU with integrated GPU (or server mobo with built-in VGA) would suffice. No need to upgrade to DDR4 if you opt for the latest-last-gen that supported DDR3.

If it's already in IT mode and Unraid detected drives fine then nothing else is needed. Connecting via USB will work (e.g. passing a USB device to a VM) but then if writing is not important then you can simply use dockers. I have little experience with FlexRAID so not too sure on most efficient migration.

Problems with your USB stick / port for sure. Your USB stick is in read-only mode after boot, which usually happens if it drops offline (e.g. failed port, reset port, shorted port etc. many reasons).

Others have mentioned how Unraid parity is superior to RAID-1 (to be exact, RAID-1E but that's academic). What I'd like to point out is you are probably confused about backup, RAID mirror and Unraid parity. A backup is a complete, independent and redundant copy of your original data. Complete = you don't need anything else to recover the data other than the copy itself Independent = operations not performed directly on the copy does not affect the copy Redundant = the copy is only accessed if (a) data needs to be recovered from the copy and (b) the copy needs to be updated A RAID-1 (i.e. mirror) is NOT a backup since it fails the independence and redundancy tests. When something changes the data, the mirror copy is automatically and immediately changed too. Both mirrors are equally likely to be accessed in regular uses. (Just think for example, you accidentally delete your wedding photo, can you recover it with a RAID-1 mirror? Answer is no because the mirrored copy also deletes the photo as soon as the original is deleted). A (Unraid) parity is NOT a backup because it fails the completeness test i.e. recovering data requires data from other disks to reconstruct the missing piece.

Hard to understand what you are trying to do. What is the total used capacity of your Synology server? What is the total available storage of your Unraid server? I think Synology runs on RAID so you can't really do a one-by-one disk transfer between the Synology and Unraid servers since data is striped on the Synology volume. The entire volume has to be moved out together.

That is a client OS problem, not an Unraid (host) problem. Unraid simply passes through a PCIe device - it doesn't say on the tin if the PCIe device is a GPU or not. The client OS detects the GPU and decides whether to use it for outputting video or not. You can potentially work-around it by setting up both VNC display and additional GPU. However, if the client OS decides "oh we have a GPU" and uses it for display then it won't work. No way to know for sure without actually trying it out.

Trial and error. There are so many ways a USB port can fail that it's kinda hard to verify all causes.

Which USB controller? Append what in flash? Are you you have not passed through the controller on which your Unraid USB stick is plugged in?

Any reason why you are not on the latest stable? Hard to troubleshoot if not on similar kernel.

Can your server even boot? i.e. do you see the login prompt on your monitor? If yes, login using your root credential and on the command line, type diagnostics That command should create the diagnostics zip for you to attach so others can help have a look. Also, if the server does not have an IP then it's either a hardware problem (e.g. failed NIC) or network problem (e.g. not properly plugged into router and/or router doesn't work and/or incorrect custom network settings). If your server doesn't even boot then you need work on creating a working USB stick first.

Your USB stick could have dropped offline. If there's no error, it could be a faulty USB port so maybe try a different port first.

The Unraid display driver is very basic so you almost certainly will need to set up a VM to better utilise the GPU.

I'll stick to unionfs for now. It's not broken for me so not seeing any need to migrate to mergefs.