Converted

I had reserved 25% more space for the metadata, and copied the old to the new and it fit (as expected).
But seems Plex wanted to do some database update and it immediately ran out of space. Turns out BTRFS was taking about 25% more space to store than XFS! So it used up all of the excess and the upgrade failed.
Going back to XFS for the metadata. I am keeping in a loopback file to avoid the huge file count and associated headaches on the cache drive.

Sorry - you don't pass through IOMMU groups. The IOMMU groups determine if the passthrough will work.
Related to your GPU pass through, I have not experienced the issue you mention with white pixels. It may be something with the video card drivers (I'd make sure running latest Nvidia drivers). Could also have to do with USB passthrough I suppose. If drivers are up to date I would ignore it for now. Once everything is passed through, and if it continues, then focus on that.
Sorry don't know what you mean by "group" 15 and 27 have same ID numbers. If you follow the tutorial above, post the results of the queries, including the one that shows "RESET" statuses, and I'll have a look and may be be able to understand what you are talking about. You really need USB devices to be installed for it to be useful. You also need to remove the "vfio-pci.ids=" from the syslinux.cfg file before running the commands.

You can always reformat an array disk. The format is nothing but data to unRAID, and parity will be reflected.
The easiest way is to stop the array, and change the filesystem on that drive to RFS or BTRFS. Then start the array. it will appear unformatted, and you can format it to the new FS. Then you can stop the array again, change the filesystem back to XFS, and start the array again. The disk will again show unformatted, and you can format it to XFS. You now have a freshly formatted XFS disk.

I'll be more direct. DO NOT buy a controller based on the Marvell chipset for use with unRAID.
May appear to work, but there have just been too many disks that get dropped offline because of these controllers, especially with VMs.
For about $50 you can get an LSI 9201-8i, which give 8 internal ports with no flashing. There are a plethora of similar controllers (e.g., LSI 9211-8i, Dell H310, IBM M1015) that can be flashed into IT mode that are equally good. But don't get a Marvell card.

There is a free tool called "TeamViewer that you can install in Windows on your home network. And you can install the Teamviewer client on a variety of devices (even phone and tablet).
Once installed, you can access your Windows workstation from a computer on the internet. Obviously you want a strong password, but it is hardened for Internet use and won't be hacked (or at least the risk is very low). Once connected you are remote controlling the workstation, which would let you access your files as though you were sitting at home. It also has upload/download features depending on the client you are using.
Is this what you are looking to do?

I saw this thread for first time today.
I have a question about changing the controller to virtio-scsi.
1 - How is this different than making the disk img into a sparse file? I've seen instructions on re-sparsifying an .img file posted.
2 - If basically the same result, which is better method?
3 - If there is plenty of free space on the SSD, is there any big benefit of releasing the blocks to trim?
4 - I have had problems with sparse files confusing standard commands (even cp and 7zip), and abandoned using them. Is this strongly recommended? Or just an option if your SSD size is tight.
@Marv - I am seeing same thing.
Below is my defrag schedule.
The C: drive is a .img located on an NVMe showing solid state
The D: drive is a .img file located on a hard disk (unassigned device) showing hard disk.
The Recovery and bottom one (volume faa...) - I have no idea what they are used for, but they are also showing solid state.
So there seems some info is being communicated from KVM on the nature of the underlying media containing the IMG. This is unexpected but pretty cool.
I wonder if you moved the .IMG file to a hard disk and tried to use it, if it would show it was now on a hard disk?? Assuming yes.

I have to work on the "seamless" part. They are on 2 different servers and IP addresses are different. But it is enough that I know how and can assist my wife to get to her content!
Important that Plex DVR can continue to record livetv - anything missed cannot be recovered!

You might consider a second license at some point in the future. Many of us that put our eggs in the unRAID basket decide to stand up a backup server. Until recently my backup server has been data backup only. But now I am setting things up so that i can switch my Dockers and VM over to my backup server if even the primary should have issues and I need to take it down. A backup key could be repurposed to use on the PROD server if needed.

Yep - i said basically same thing earlier in the thread, but you said it better.
Up until six months to a year ago, I would have said I could live forever on the version d'jour. Now I do not feel that way. 6 months? probably. A year? maybe. 2 years? probably not. But this scenario seems very very unlikely. Tom is showing no signs of slowing. A sale seems more likely. And if he does get hit by a bus, he has already said that information about the proprietary parts of unRAID would be released to enable what @wayner mentions above.
Related to the USB stick - understand that Tom uses this to protect his asset from piracy. And it works very well from what I have seen. And debating that the USB is an unreliable device, the way unRAID uses it, is not supported by the facts. In fact quite the opposite. The USB dependency is not going to change any time soon. I don't think comparing it to a USB stick used in the car is valid. You have condensation, large temperature variations, vibrations/jarring, in and out of your pocket, and continuous use. I would not expect such a device to do very well in the long term. But many here have unRAID keys that are 2, 5, even 10 years old that work fine. They are very lightly used and in a very steady operating environment. The biggest risk is physical damage, like snapping it off while walking past. Which is why the more compact sticks are recommended. My advice - don't sweat it.

This is true unless you are doing VMs or limiting Dockers to specific cores. There are two basic issues. One is that the # of cores and/or core pairings may be different. And for passthrough of hardware, the IOMMU groups and hardware addresses are difference. It is a good idea for VMs to recreate that VM template on the new motherboard, pointing to the existing vdisk file. Go back to the video or instructions you originally used and go through the process on the new motherboard. And to remove core limitations on your Dockers in the old motherboard configuration, and then rethink those in light of the new CPU once you move them over.