JonathanM

Isolate the Unraid box from your LAN to see if it's a device on your network.

IPMI uses the dedicated graphics chip built in to the IPMI module, so if the OS (Unraid) is outputting video to another GPU, it won't show up in IPMI. Have you mucked with the BIOS settings? Are you SURE it's not booting? It could be coming up just fine without showing anything on that particular screen. Check to see if the NIC's MAC is showing up in your router's attached devices area.

How I handle this sort of thing is a dedicated VM with all the good tools, like gparted and such. Temporarily assign the target vdisk as a second drive to your utility VM, load up the disk utilities and do what you need to do.

Unclear if you are aware that rebuilt disks must have their original filesystems, as the filesystem is part of the emulation. To get a new filesystem you must add a new disk, or format an existing disk. Formatting erases all the data. There is a sticky thread discussing methods of moving data around to change filesystems.

How does it act if you assign the VM 4GB of RAM?

Read the link that was generated when you (or I) typed the words docker run.

Because Unraid is basically a new install every boot, the sdX designations can and do change when there are hardware changes, and sometimes when there are only software changes. Any scripted disk reference needs to use something OTHER than the sdX designation or you risk applying the command to the completely wrong disk.

Those server style HBA's were never designed to be in a normal desktop or tower case. They rely on rack mount style ventilation where there is a fan wall or similar that forces a large amount of air across all the slots. If you are using it in a consumer grade case you must add ducting or direct fan flow.

Install nomachine in the VM and your desktop. Use that instead of VNC.

If the inside is much warmer, you need better ventilation.

Two schools of thought, which you choose depends on you. First, traditionally multiple shares are created, as many as make sense to you, for example, tvshows, movies, pictures, music, documents, downloads, etc. You can assign array disks or pools to contain portions of those shares, assign different user access permissions, as granular as you want. Second, create just one media share that has subfolders for different types of content as well as a subfolder structure for downloads of that content. The advantage (the only advantage IMHO) is that you can optionally keep seeding torrents of content without duplicating the storage needs. If you don't use torrents extensively, or are ok with duplicating files that you wish to seed, I definitely recommend the traditional way. Performance will be similar if not identical with either option. It's just a question of granularity of organization and access control.

Go to the support link of each one and make a choice based on issues and responses.

It's not so much how many, but which ones specifically, and what paths are being written to by the apps inside the containers. The app paths aren't something that is viewable in Unraid, you must look at the app's internal configurations and verify that any path storing data that needs to be persistent is mapped to a spot on the array or appdata. The mappings are easily viewable using the Unraid GUI, but the internal app paths to compare them to aren't. All that said, your screenshot doesn't have anything that jumps out at me as bad, you just have some hefty containers. I'd bump up to 30GB and keep an eye on things, if the sizes stay relatively the same over several weeks you are good. Every time a container is updated, the newly installed parts are added to the image, then the newly unused parts are removed. It's the time between downloading the updates and cleaning things up that causes the warning when you are close to the size limit. Filling the image can be fatal though, so it's wise to keep a healthy margin of free space for the update process, and keep an eye on it to make sure the usage isn't creeping up over time.

I'm having a hard time thinking of a situation where an emulated drive should ever be formatted. If it's unmountable it needs a file system check. Normally an emulated drive will be indistinguishable from the drive that has been dropped because of a write error, as long as parity was completely in sync when the drive was dropped. All the normal things you can do to a physical drive can be done to the emulated drive, such as reading the existing data, writing new data, formatting it, scanning for filesystem errors, etc.

I asked a long time ago to move the format option to the individual drive pages, possibly next to the selection of format type, or even better underneath the file system check area so you have to read through the file system check area before you even get to the format button. I don't believe it's a good idea to have a universal format option on the main page. The pushback to my suggestion was that a new array would take forever to go through each drive one at a time to format. My counter was that totally new array drives are a very limited situation, and it's worth the extra time to show the new user where to maintain each disk, in the same area with smart information and file system checks. I felt like I was talking to a wall, nothing was ever acknowledged.