chaz

Members
  • Posts

    8
  • Joined

  • Last visited

Everything posted by chaz

  1. No worries, you have still been helpful by putting me in touch with hackerman! Cheers @hackerman-lsio it doesn’t seem to be running everyday at 3am Is there a way to check if the cron is actually scheduled? If the crawlbot setting in diskover.cfg is set, does it mean the cronjob is disabled or vice versa? Appreciate your help!
  2. Hi @saarg please let me know if you can help with setting up the crawlers using the cron job settings. I am trying to get the crawling working on a daily basis. I have changed the diskover.cfg to this: [crawlbot] ; continuous scanner ; time to sleep (seconds) between checking for directory changes sleeptime = 86400 ; number of threads for checking directories, setting this to num of cores x2 is a good starting point threads = 8 my template has the following settings: RUN_ON_START=true USE_CRON=true if I go to the \config\diskover\crontabs folder, there is a file named "abc" with the following: 0 3 * * * /app/dispatcher.sh >> /config/log/diskover/dispatcher.log 2>&1 It seems I have to restart the diskover docker to get the crawler to work. Do I have to setup a User Scripts plugins schedule to shell into the docker container and call the python script on a set interval? e.g. "$ python /path/to/diskover.py -d /rootpath/you/want/to/crawl -i diskover-indexname -a -O"
  3. @shirosai thank you very much for your effort on this! I have found it to be very fast in crawling and searching 👌😊 I wanted to ask if anyone knows about crawling using the workers. I don't want it to spin up the drives constantly, so I was thinking of setting up the diskover.cfg to run every day like this: [crawlbot] ; continuous scanner ; time to sleep (seconds) between checking for directory changes sleeptime = 86400 ; number of threads for checking directories, setting this to num of cores x2 is a good starting point threads = 8 Is this the right way to do it, or do I need to use a cronjob? I can see a flag in the template Run a crawl on as a cron job (optional): false Container Variable: USE_CRON I am unsure if I can call something in the docker container to trigger the workers/crawler to run through the user scripts plugin, or do I need to find a way to install the cron management UIs listed on the Github page (crontab-ui or cronkeep). Cheers
  4. Changing the VM folder name under the domains folder seems to have fixed this for me as well. Thanks user2352!
  5. Jon, no it didn't make a difference after removing the edits in XML mode. That is one of the first things I did, sorry, I should have mentioned my debugging steps. I also replicated the issue using a dummy VM: Made a new Win 10 VM using the same image and made a change to the XML file Editing in Form view (This works ok, updated fine) Then I removed my edit in XML view Made a change in Form view Pressed Update, now it's stuck in Updating.... So it may be a limitation/bug in Unraid at this point. Here is my Win 10 XML that is not updating using form view: <?xml version='1.0' encoding='UTF-8'?> <domain type='kvm'> <name>W10_SURVEILLANCE_PC</name> <uuid>1c7ccfe3-c09d-56a9-f441-de36ef5cd86f</uuid> <metadata> <vmtemplate xmlns="unraid" name="Windows 10" icon="windows.png" os="windows10"/> </metadata> <memory unit='KiB'>4194304</memory> <currentMemory unit='KiB'>4194304</currentMemory> <memoryBacking> <nosharepages/> </memoryBacking> <vcpu placement='static'>8</vcpu> <cputune> <vcpupin vcpu='0' cpuset='2'/> <vcpupin vcpu='1' cpuset='8'/> <vcpupin vcpu='2' cpuset='3'/> <vcpupin vcpu='3' cpuset='9'/> <vcpupin vcpu='4' cpuset='4'/> <vcpupin vcpu='5' cpuset='10'/> <vcpupin vcpu='6' cpuset='5'/> <vcpupin vcpu='7' cpuset='11'/> </cputune> <os> <type arch='x86_64' machine='pc-i440fx-3.0'>hvm</type> <loader readonly='yes' type='pflash'>/usr/share/qemu/ovmf-x64/OVMF_CODE-pure-efi.fd</loader> <nvram>/etc/libvirt/qemu/nvram/1c7ccfe3-c09d-56a9-f441-de36ef5cd86f_VARS-pure-efi.fd</nvram> </os> <features> <acpi/> <apic/> <hyperv> <relaxed state='on'/> <vapic state='on'/> <spinlocks state='on' retries='8191'/> <vendor_id state='on' value='none'/> </hyperv> </features> <cpu mode='host-passthrough' check='none'> <topology sockets='1' cores='4' threads='2'/> </cpu> <clock offset='localtime'> <timer name='hypervclock' present='yes'/> <timer name='hpet' present='no'/> </clock> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>restart</on_crash> <devices> <emulator>/usr/local/sbin/qemu</emulator> <disk type='file' device='disk'> <driver name='qemu' type='raw' cache='writeback'/> <source file='/mnt/user/domains/Windows 10 - Surveillance PC/vdisk1.img'/> <target dev='hdc' bus='virtio'/> <boot order='1'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x05' function='0x0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/Win10_1809Oct_EnglishInternational_x64.iso'/> <target dev='hda' bus='ide'/> <readonly/> <boot order='2'/> <address type='drive' controller='0' bus='0' target='0' unit='0'/> </disk> <disk type='file' device='cdrom'> <driver name='qemu' type='raw'/> <source file='/mnt/user/isos/virtio-win-0.1.160-1.iso'/> <target dev='hdb' bus='ide'/> <readonly/> <address type='drive' controller='0' bus='0' target='0' unit='1'/> </disk> <controller type='usb' index='0' model='ich9-ehci1'> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x7'/> </controller> <controller type='usb' index='0' model='ich9-uhci1'> <master startport='0'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x0' multifunction='on'/> </controller> <controller type='usb' index='0' model='ich9-uhci2'> <master startport='2'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x1'/> </controller> <controller type='usb' index='0' model='ich9-uhci3'> <master startport='4'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x07' function='0x2'/> </controller> <controller type='pci' index='0' model='pci-root'/> <controller type='ide' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x1'/> </controller> <controller type='virtio-serial' index='0'> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </controller> <interface type='bridge'> <mac address='52:54:00:50:a8:3f'/> <source bridge='br0'/> <model type='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x03' function='0x0'/> </interface> <serial type='pty'> <target type='isa-serial' port='0'> <model name='isa-serial'/> </target> </serial> <console type='pty'> <target type='serial' port='0'/> </console> <channel type='unix'> <target type='virtio' name='org.qemu.guest_agent.0'/> <address type='virtio-serial' controller='0' bus='0' port='1'/> </channel> <input type='tablet' bus='usb'> <address type='usb' bus='0' port='1'/> </input> <input type='mouse' bus='ps2'/> <input type='keyboard' bus='ps2'/> <hostdev mode='subsystem' type='pci' managed='yes'> <driver name='vfio'/> <source> <address domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </source> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/> </hostdev> <memballoon model='none'/> </devices> </domain>
  6. Yes I did edit it once, the only thing I added was a sound setting. <sound model=‘ich9’></sound> Usually is it possible to go back to the normal UI after editing in the XML mode?
  7. I have attached the diagnostic report, hope it helps to narrow down the issue! tower-diagnostics-20181203-2351.zip
  8. Hi All, I am trying to update my VM config, however, I cannot change any of the settings. It gets stuck after pressing the "Update" button and shows "Updating...". I did some searching and found a previous thread which was relating to the cache drive being full. My cache drive is nowhere near full. Could this be due to a corrupted XML file relating to the Windows 10 VM I am trying to change the settings for (I can't even change the name of the VM)? Any help is much appreciated. Cheers!