hawihoney

Members
  • Posts

    3416
  • Joined

  • Last visited

  • Days Won

    6

Everything posted by hawihoney

  1. Can't reach my server any longer after issuing the first steps. Even local access via IP doee not work any longer ecuase access to local IP tries to access a cryptic URL. Some year ago I tried to certificate and use SSL when this feature was introduced. It ended the same. I was locked out. I remember that now. I can't remember what I did to get access again. Any help is highly appreciated. Edit: Missing or empty GUID is shown now on registration page. What a €%*@
  2. For easy management of VMs, I would vote for a dropdown selection list on the VM create/edit form. 1.) This dropdown selection list would include all unused devices *). 2.) It would be possible to add and remove devices from the VM create/edit form. The dropdown selection list will reflect added/removed devices. 3.) After VM creation, the devices used for this VM will get the passed-thru indicator within Unassigned Devices. 4.) A standard XML block like the following will be added to this VM for every selected device: <devices> <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='none'/> <source dev='/dev/disk/by-id/********'/> <serial>********</serial> <target dev='vd*' bus='virtio'/> <backingStore/> </disk> </devices> *) This list would contain all non-array and non-boot devices that are not marked as passed-thru within Unassigned Devices and are not selected on the current VM create/edit form.
  3. Ah, ok. Good to know. Everythings connected here.
  4. In one of my VMs I found this in syslog. A running parity check dropped from 122 MB/s to 17 MB/s: Mar 10 13:04:16 TowerVM02 kernel: clocksource: timekeeping watchdog on CPU6: Marking clocksource 'tsc' as unstable because the skew is too large: Mar 10 13:04:16 TowerVM02 kernel: clocksource: 'acpi_pm' wd_now: 3664fc wd_last: 62e7a2 mask: ffffff Mar 10 13:04:16 TowerVM02 kernel: clocksource: 'tsc' cs_now: 43f8233e3b2c cs_last: 43f59d044437 mask: ffffffffffffffff Mar 10 13:04:16 TowerVM02 kernel: tsc: Marking TSC unstable due to clocksource watchdog Mar 10 13:04:16 TowerVM02 kernel: TSC found unstable after boot, most likely due to broken BIOS. Use 'tsc=unstable'. Mar 10 13:04:16 TowerVM02 kernel: sched_clock: Marking unstable (26599124145134, 33401162)<-(26599178070430, -20523118) Mar 10 13:04:16 TowerVM02 kernel: clocksource: Switched to clocksource acpi_pm What's that? BIOS is OVMF from Unraid 6.9.1. Thanks in advance.
  5. For those of us, who use the NVIDIA driver: Do we need to delete the plugin before update and reinstall after update (with Docker stop, Docker start). Will it stay that way?
  6. Just tested it on 6.9.1. I can't confirm that. It's working here.
  7. HBA Controller: LSI 9300-8e Backplane: Supermicro BPN-SAS2-EL1 Drives changing behaviour of Unraid and HBA: 5x HGST HUS726020ALA610 (total 24 drives at backplane) These 5x SATA devices behave like a SAS device. After install of 6.9.0/6.9.1 the Unraid server hosting five of these HUS726020ALA610 drives behaves completely different. 1.) For the first time in many years, the Activity LED on the Drive Carrier is "solid on" (blue). The description for this is called "SAS/NVMe drive installed". No other SATA drive models showed or show "solid on". They report "I/O activity (blinking blue)" but no "solid blue". 2.) If these drives are connected to a HBA, the HBA behaves different too. Unraid fails to spindown drives. In fact all 24 drives are affected and don't spin down any longer. Standard spindown is broken at this point. "SAS spindown" app needs to be installed to overcome that problem. 3.) Unraid GUI fails to show SMART values. Again all 24 drives are affected. The "Attributes" section on the SMART page is empty. "smartctl -a" still works. Before somebody asks: The drives were spun up while trying to show SMART values in Unraud GUI. 4.) In two identical VMs the disk-by-id prefix for all drives changes from "ata*" to "scsi*". When removing the HGST SATA drives it changes back to "ata*". Weird is, while /dev/disk/by-id shows "scsi*" prefix, Unraid/Tools/System Devices still shows "ATA" instead: ata-TOSHIBA_HDWE140_Y75DK1KLF58D --> scsi-3500003990b8815e3 Is it possible that various drives are SATA drives but report a SAS drive to the controller? Is it possible that the MegaRAID driver has a bug? Perhaps this is the reason for other peoples spindown problems.
  8. Please have a look at the two screenshots. They show the editor windows of two existing VMs. The Broadcom devices are marked gray (unavailable) if they are in use. The USB devices stay available even if in use. IMHO, the USB devices must be marked gray (unavailable) as well if they are in use.
  9. Sorry to ask. What's the opposite (spinup) command? GUI and system now mismatch. Some disks "think" they are spun up - but aren't and vice versa. Plex puts contents of some disks in the trashbin because the system "thinks" disks are spun up and Plex can't read them.
  10. Why not add the unused disks to the array?
  11. Since 6.9.0 no SATA disks spin down in an array. Every 1 hour I do see the commands in syslog to spin down the disks, but they don't spin down. I stopped all docker containers, removed plugins to the minimum (Community Applications, Unassigned Devices, User Scripts, Nerd Tools for screen and python), no fancy fan scripts. The disks simply ignore the spin down commands. HBA is LSI 9300-8e, disks are mixed 6TB to 2TB. It worked for all years here up to and including 6.8.3. Now with 6.9.0 it stopped. Is there a way to brute force spin down SATA devices? If there's none I'm forced to go back to 6.8.3. IMHO, it's one of the relevant parts of Unraid to spin down unused disks. Mar 5 04:59:18 TowerVM02 emhttpd: spinning down /dev/sde Mar 5 04:59:36 TowerVM02 emhttpd: spinning down /dev/sdi Mar 5 04:59:44 TowerVM02 emhttpd: spinning down /dev/sdw Mar 5 05:00:47 TowerVM02 emhttpd: spinning down /dev/sdp Mar 5 05:00:58 TowerVM02 emhttpd: spinning down /dev/sdk Mar 5 05:01:03 TowerVM02 emhttpd: spinning down /dev/sdj Mar 5 05:01:11 TowerVM02 emhttpd: spinning down /dev/sdu Mar 5 05:01:18 TowerVM02 emhttpd: spinning down /dev/sdv Mar 5 05:01:51 TowerVM02 emhttpd: spinning down /dev/sdb Mar 5 05:01:55 TowerVM02 emhttpd: spinning down /dev/sdh Mar 5 05:01:56 TowerVM02 emhttpd: spinning down /dev/sds Mar 5 05:02:01 TowerVM02 emhttpd: spinning down /dev/sdy Mar 5 05:02:01 TowerVM02 emhttpd: spinning down /dev/sdq Mar 5 05:02:03 TowerVM02 emhttpd: spinning down /dev/sdc Mar 5 05:02:08 TowerVM02 emhttpd: spinning down /dev/sdr Mar 5 05:02:10 TowerVM02 emhttpd: spinning down /dev/sdo Mar 5 05:02:11 TowerVM02 emhttpd: spinning down /dev/sdx Mar 5 05:02:11 TowerVM02 emhttpd: spinning down /dev/sdl Mar 5 05:02:13 TowerVM02 emhttpd: spinning down /dev/sdf Mar 5 05:02:14 TowerVM02 emhttpd: spinning down /dev/sdd Mar 5 05:02:14 TowerVM02 emhttpd: spinning down /dev/sdn Mar 5 05:42:15 TowerVM02 emhttpd: spinning down /dev/sdm Mar 5 05:42:15 TowerVM02 emhttpd: spinning down /dev/sdg Mar 5 05:42:15 TowerVM02 emhttpd: spinning down /dev/sdt # Nothing between here Mar 5 05:59:19 TowerVM02 emhttpd: spinning down /dev/sde Mar 5 05:59:37 TowerVM02 emhttpd: spinning down /dev/sdi Mar 5 05:59:45 TowerVM02 emhttpd: spinning down /dev/sdw Mar 5 06:00:48 TowerVM02 emhttpd: spinning down /dev/sdp Mar 5 06:00:59 TowerVM02 emhttpd: spinning down /dev/sdk Mar 5 06:01:04 TowerVM02 emhttpd: spinning down /dev/sdj Mar 5 06:01:12 TowerVM02 emhttpd: spinning down /dev/sdu Mar 5 06:01:19 TowerVM02 emhttpd: spinning down /dev/sdv Mar 5 06:01:52 TowerVM02 emhttpd: spinning down /dev/sdb Mar 5 06:01:56 TowerVM02 emhttpd: spinning down /dev/sdh Mar 5 06:01:58 TowerVM02 emhttpd: spinning down /dev/sds Mar 5 06:02:02 TowerVM02 emhttpd: spinning down /dev/sdy Mar 5 06:02:02 TowerVM02 emhttpd: spinning down /dev/sdq Mar 5 06:02:04 TowerVM02 emhttpd: spinning down /dev/sdc Mar 5 06:02:09 TowerVM02 emhttpd: spinning down /dev/sdr Mar 5 06:02:11 TowerVM02 emhttpd: spinning down /dev/sdo Mar 5 06:02:13 TowerVM02 emhttpd: spinning down /dev/sdx Mar 5 06:02:13 TowerVM02 emhttpd: spinning down /dev/sdl Mar 5 06:02:14 TowerVM02 emhttpd: spinning down /dev/sdf Mar 5 06:02:15 TowerVM02 emhttpd: spinning down /dev/sdd Mar 5 06:02:15 TowerVM02 emhttpd: spinning down /dev/sdn Mar 5 06:42:16 TowerVM02 emhttpd: spinning down /dev/sdm Mar 5 06:42:16 TowerVM02 emhttpd: spinning down /dev/sdg Mar 5 06:42:16 TowerVM02 emhttpd: spinning down /dev/sdt # Nothing between here Mar 5 06:59:20 TowerVM02 emhttpd: spinning down /dev/sde Mar 5 06:59:38 TowerVM02 emhttpd: spinning down /dev/sdi Mar 5 06:59:46 TowerVM02 emhttpd: spinning down /dev/sdw Mar 5 07:00:49 TowerVM02 emhttpd: spinning down /dev/sdp Mar 5 07:01:00 TowerVM02 emhttpd: spinning down /dev/sdk Mar 5 07:01:05 TowerVM02 emhttpd: spinning down /dev/sdj Mar 5 07:01:13 TowerVM02 emhttpd: spinning down /dev/sdu Mar 5 07:01:20 TowerVM02 emhttpd: spinning down /dev/sdv Mar 5 07:01:53 TowerVM02 emhttpd: spinning down /dev/sdb Mar 5 07:01:57 TowerVM02 emhttpd: spinning down /dev/sdh Mar 5 07:01:59 TowerVM02 emhttpd: spinning down /dev/sds Mar 5 07:02:03 TowerVM02 emhttpd: spinning down /dev/sdy Mar 5 07:02:03 TowerVM02 emhttpd: spinning down /dev/sdq Mar 5 07:02:05 TowerVM02 emhttpd: spinning down /dev/sdc Mar 5 07:02:10 TowerVM02 emhttpd: spinning down /dev/sdr Mar 5 07:02:12 TowerVM02 emhttpd: spinning down /dev/sdo Mar 5 07:02:14 TowerVM02 emhttpd: spinning down /dev/sdx Mar 5 07:02:14 TowerVM02 emhttpd: spinning down /dev/sdl Mar 5 07:02:15 TowerVM02 emhttpd: spinning down /dev/sdf Mar 5 07:02:16 TowerVM02 emhttpd: spinning down /dev/sdd Mar 5 07:02:16 TowerVM02 emhttpd: spinning down /dev/sdn
  12. I add a new bug report because this is a little bit different. Here Unraid is running within VMs. Funny thing: Two identical VMs, one spins down, the other does not spin down. Both VMs are nearly bare, just two dockers (MakeMKV, MKVToolNix), four plugins (Community Applications, Unassigned Devices, User Scripts, Nerd Tools) are all that is running. All disks of the two VMs are attached to two LSI 9300-8e HBAs. Backplanes are identical. VM #1 (TowerVM01): Spins down as usual. VM #2 (TowerVM02): Does not spin down at all, hitting the Spin Down button does nothing. The only difference is the count of pcie-root-port entries in VM #2. I did describe that in the following forum post. But this was never a problem for the spin down behaviour on 6.8.3. towervm01-diagnostics-20210304-1837.zip towervm02-diagnostics-20210304-1835.zip
  13. I do have two system/appdata folders. One on an unassigned device and one on an array device. The system share is set to "Use cache=No". E.g.: /mnt/disk17/system/ /mnt/disks/NVMe1/system/ VMs are running on array, Dockers are split between both. Docker/VM settings are set to: /mnt/disk17/system/docker.img /mnt/disk17/system/libvirt.img Should I expect problems?
  14. I did create two nearly identical Slackware VMs. The only difference between both is a different LSI HBA adapter passed through and a different IMG file. The GUI view of both VMs looks identical. But the XML view of both differs a lot. One of the XMLs is a lot bigger. It does contain 129 controller entries like shown below. What are these? Can I remove them? Starting that VM does need noticable more time. <controller type='pci' index='1' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='1' port='0x10'/> <alias name='pci.1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/> </controller> <controller type='pci' index='2' model='pcie-root-port'> <model name='pcie-root-port'/> <target chassis='2' port='0x11'/> <alias name='pci.2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/> </controller>
  15. I'm fighting with an executable that I would like to call within a container. Could please somebody tell me what I'm doing wrong? I tried to put " around all possible combinations of options - without success. Any help is highly appreciated. Many thanks in advance. docker exec MKVToolNix /usr/bin/mkvpropedit --edit track:1 --delete --edit track:2 --delete --edit track:3 --delete --edit track:4 --delete "/storage/disk1/Test/Test.mkv" Error: More than one file name has been given ('track:2' and 'track:3').
  16. Thanks. Seems that single-thread performance is more important then on Unraid parity-check/-rebuild than number of CPUs, cores.
  17. From my own experience it looks as if parity-check/-rebuild runs single threaded? Is this true?
  18. Seems that this has been fixed in PMS recently: https://forums.plex.tv/t/plex-media-server/30447/396
  19. This is a JBOD DAS. No rear connectors for a motherboard. It has two backplanes (24 and 21 drives). You can connect an external HBA like LSI-9300-8e at the IN-ports at the rear and connect other DAS enclosures at the OUT-ports at the rear. The backplanes come with expanders for these connections. On the pictures you can see EL2 type backplanes. These have expander and failover features. These boxes are heavy, professional and loud as hell. I love them. I've build several SC846 with corresponding DAS enclosures for Unraid. The biggest had 72 drives. With the current Unraid license rules you need several licenses and HBAs passed thru because 45 drives require two or more arrays. I would like to build new systems with SC847 DAS but I don't know how to pass thru 21 drives to a second array instead of an additional HBA. I have some fear that Unassigned Devices has problems with dozens drives on the main page. https://www.supermicro.com/en/products/chassis/4U/847/SC847E26-RJBOD1 ***Edit***: The mentioned system with 72 drives, 3 enclosures, 2*2690v2, Nvidia 1050ti, 3*HBA, 196GB RAM, 2*1TB M.2 draws around 700W.
  20. First why: In the last two years we did setup several big Unraid servers with attached "Direct Attached Storage" enclosures. Usually the bare metal server did host several HBAs and every attached "Direct Attached Storage" enclosure was one individual Unraid array with it's own license stick and it's own HBA passed thru to every Unraid VM. With this setup we could drive several Unraid arrays (22 data drives, 2 parity drives each) as one server. Using the 36/45 drive enclosures from Supermicro now we would like to change that: Only one HBA per bare metal, using the expander feature of the bigger backplane, driving two arrays. In this setup we can't passthru a second HBA for the Unraid VM. E.g. for the 45 drive this would result in one Unraid array of 24 drives and one Unraid array of 21 drives. All attached to one HBA using the expander feature of the 24-drive backplane. This means: We need to passthru 21 drives to the Unraid VM. Question(s): After reading lots of information I'm confused now about the correct syntax and keywords I need to use: 1.) virsh manual? virsh attach-disk TowerVM01 /dev/disk/by-id/ata-TOSHIBA_MG07ACA12TE_3010A09AF96G --serial TOSHIBA_MG07ACA12TE_3010A09AF96G --type disk virsh attach-disk TowerVM01 /dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX11D469YZL4 --serial WDC_WD60EFRX-68L0BN1_WD-WX11D469YZL4 --type disk 2.) XML? <disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/disk/by-id/ata-TOSHIBA_MG07ACA12TE_3010A09AF96G'/> </disk> <disk type='block' device='disk'> <driver name='qemu' type='raw'/> <source dev='/dev/disk/by-id/ata-WDC_WD60EFRX-68L0BN1_WD-WX11D469YZL4'/> </disk> Would these work? Any help is highly appreciated.
  21. Since two days I try to install a lightweight graphical Linux distribution in a VM. I started with Ubuntu and Debian. I did download their ISOs leaving everything else default on the VM creation page. Opening VNC I'm always stuck on a BIOS page. Sometimes I see a counter "Press a key ... startup.nsh". Whatever I do, the only thing I can do is enter a BIOS or leave a BIOS seeing the startup.nsh counter again.. Call me stupid but I don't get it. Installing a Windows VM on the other hand was easy as 1,2,3. What am I doing wrong? Any help is highly appreciated.
  22. I did install rar and unrar from the Nerd-Pack plugin. The plugin can be installed from the Community Applications (Apps).