JonathanM

Moderators
  • Posts

    16131
  • Joined

  • Last visited

  • Days Won

    65

JonathanM last won the day on November 11 2023

JonathanM had the most liked content!

Retained

  • Member Title
    unAdvanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

JonathanM's Achievements

Grand Master

Grand Master (14/14)

2.3k

Reputation

204

Community Answers

  1. Don't do that. You need to leave resources available for the host (Unraid) to emulate the motherboard and other I/O. At the very least leave CPU 0 available for Unraid. Since you only have 4 threads, I'd only use CPU2 and CPU3 for the VM, maybe try with only the last thread for the VM and leave the other three for the host. That may also be too much, depending on how much RAM the system has. If the physical box has 32GB, 8 for the VM should be fine. If it has 16 or less, reduce the VM to 4096. The more resources you tie to the VM, the slower the host is going to run, which in turn slows the VM way down. Give the VM the absolute minimum and add a little at a time until performance doesn't increase.
  2. Just the reverse array -> cache, or cache only The advantage of having the cache primary and array be a secondary with a move to cache setting is that if you ever accidentally fill the cache and the minimum free space is set correctly the excess data will go to the array, then when the cache has room, the mover will put the data back on the cache. Cache only will give an out of space error when it gets below the minimum free space set.
  3. Yes, the parity array is great for mass storage, very bad for random I/O, especially random writes. SSD or NVME is a must for vdisks.
  4. Yep, that would be why the VM is dog slow. vdisks should be on fast pools, not parity protected array disks.
  5. All support questions for specific containers should be posted in their thread, not spread out across the forum. That way people can easily see what others have asked, and the answers they received. Many problems have already been asked and answered.
  6. At any point did you format a drive? If so, you erased all the existing files.
  7. 1. What drive is the VM using for vdisk or passthrough? 2. Try changing the RAM to 8GB
  8. Perhaps post in the support thread specific to your container. In the Unraid GUI, click on the container icon, and select support.
  9. Obviously before messing with it make a backup. Stop your HA VM, and click on the 32GB under CAPACITY. Change it to 42G, or whatever floats your boat, and apply the change. Set up a new VM with your favorite live utility OS as the ISO. https://gparted.org/livecd.php is a good option. Add the existing haos vmdk vdisk file as a disk to the new VM. Boot the new VM, it should start the utility OS, where you can use gparted to expand the partition to fill the expanded vdisk image.
  10. Which is why the Unraid regular container startup has customizable delays between containers. Black start from nothing is easier, partially running start during backup sequence is more complex, it needs even better customizations. Shutdown and startup conditionals and/or delays would be ideal. As an example, for my nextcloud stack I'd like nc to be stopped, wait for it to close completely, stop collabora, stop mariadb. Backup all three. Start mariadb, start collabora, wait for those to be ready to accept connections, start nextcloud. The arr stack is even more complex. The arr's and yt dl need to be stopped, then the nzb, then the torrent and vpn. Startup should be exactly the reverse, with ping conditionals ideal, blind delays acceptable.