• Posts

  • Joined

  • Last visited

  • Days Won


JTok last won the day on December 19 2019

JTok had the most liked content!

1 Follower

About JTok

  • Birthday August 25


  • Gender
  • URL
  • Location

Recent Profile Visitors

2582 profile views

JTok's Achievements


Apprentice (3/14)



  1. This is something I found right after the last release. It will be fixed in the next version. Glad you figured it out though. If anyone else runs into this, you can also fix it by running this from the terminal (which will force the vmbackup plugin to fully uninstall). removepkg vmbackup*
  2. Yeah, that should be the only thing you need to change. If it isn't, then I have something to fix haha
  3. @CS01-HS Your issue can be fixed by going to the Danger Zone tab and setting "Disable restrictive validation" to "Yes" @peter76 your issue can be fixed by going to the Danger Zone tab and setting "Disable custom cron validation" to "Yes" Additional Information: @CS01-HS There are limits in place to prevent people from choosing values that could be dangerous without making sure they understand them. Also, if you only need 1 backup, why not just use "Number of Backups to Keep" and set it to 1 instead of using "number of days to keep backups"? @peter76 With cron it is very complicated to validate all possible options, so I went with something that would cover most scenarios while leaving the disable switch to allow for more complex ones like yours. I've been trying to make the plugin's default state the bare minimum amount of restrictive necessary to help protect less experienced users from themselves, while still giving power users the ability to remove those restrictions and be more adventurous. Nearly every setting can can be overridden somewhere, but I know that isn't very obvious right now. Making that more apparent is on my list of things to do in a future release.
  4. Normally I would have, but I just didn't have a chance to yet. My life is still a bit of a mess after moving (I'm currently sitting on the floor while I type this because most of my furniture won't arrive for another week haha). I'm planning on incrementing the version later today though, but I wanted to get the quick and dirty fix out sooner rather than later.
  5. I finally found the issue. For some reason, several of the files had their EOL character changed when I pushed the last update (I'm blaming GitHub). As long as you have removed the broken version this should work. If you get an error saying that the plugin is already installed when you try to install this version, you will need to remove the the old version. If you have already removed the old version and are still getting an error saying that the plugin is already installed, run the following terminal command and try again. removepkg vmbackup*
  6. I just wanted to check in and say I am still working on this. Unfortunately my new ISP couldn’t get my Internet going yesterday, and had to schedule another appointment for earlier today. Which meant I wasn’t able to start on this until now. Hopefully it is a quick fix [emoji1696] Sent from my iPhone using Tapatalk
  7. Dang. Sorry for the issues with the latest version. I wasn’t having them on my server (although mine was still on 6.8.3), but I must have messed something up when I uploaded the latest version to GitHub. I am arriving at my new place this afternoon, so I’ll update my server and try to get a fix out tonight. Sent from my iPhone using Tapatalk
  8. Whoops! typed the wrong filename. I think it should work now.
  9. In light of the official release of 6.9.0 I have removed the max version restriction. I am not able to confirm how well it works this week because I am moving across several time-zones. I am also still working on a new version. As a quick heads up, the new version will be dropping support for pigz, but gzip will still work for anyone using legacy compression (this change should not be breaking or require any user input). I also fixed a few bugs, and am adding a few new features.
  10. Hello, long time no see. I am truly sorry to see so many of you have had an issue with this plugin, and it was not my intention to abandon it for as long as I have. Sadly, life had other plans (as it often does). I've recently found myself with time to tinker again, and as such I've released an update that does a few things to try and address some of the issues I am aware of. Unfortunately, I haven't been able to replicate many of the issues others are having, so my ability to test has been limited. I also can see that the operation of some of the advanced functions isn't immediately clear either. A few of the issues people have had could have been resolved with a settings change in one of the more advanced settings tabs (usually Danger Zone). I'll try to find a way to make some of those things clearer as I progress on addressing the larger issues. The big issue I'm attempting to address in the new release is the issue some people have had with the array not wanting to stop. I have adjusted how the backup scripts are checked and it will hopefully be able kill stuck ones more readily. The other thing I have done is set a max version of 6.8.3 until I have time to test on 6.9. I currently do not have a test server, so it could be a bit before I have a chance to spin one up for troubleshooting. Again, I do sincerely apologize for those that feel I left them in the lurch. Thankfully, as others have rightly pointed out, the script that the plugin uses on the back-end is much more stable and a solid way to go. I would also like to add that I am more that willing to add contributors to the project if others would like to help me maintain it. Best, JTok
  11. I tried the vmbackup from CommunityApplications but it just does not want to trigger the backup

    I have the vm's in the cash pool that is mapped to the appdata folder



    It worked prior to upgrading to version beta25

  12. For what it is worth, the direct mount did not actually fix it for me, just obfuscate it by making it so loop2/3 didn't show up in iotop. When I checked the SMART status I wound up with just as many writes as before, so I would be interested to hear your results. It seems like I might be an outlier here, so possibly I have a different issue affecting my setup.
  13. A note on this from my experience. I actually did this and it worked, but when I went to make changes to the dockers it failed and they would no longer start. I think I could have fixed it by clearing out the mountpoints, but I opted to just wipe the share and then re-add all the dockers from "my templates" which worked just fine. So, can confirm --would not recommend. I did copy the libvirt folder though and have not noticed any ill effects (...yet. haha)
  14. It's funny you mention that. I haven't rolled the workaround back yet, but I'm starting to wonder if it isn't fixing the issue so much as obfuscating it. I'm planning on rolling the fix back later today/tonight to see what happens. I got some metrics by basically doing the same thing as your script (except manually). According to SMART reporting, my cache drives are writing 16.93GB/hr. This is even though when I implemented the workaround I also moved several VMs and a few docker paths to my nvme drives just to reduce the writes further. I'd be curious to know what others are seeing.
  15. For anyone else that needs it, I was having more issues with libvirt/loop3 than docker/loop2, so I adapted @S1dney's solution from here for libvirt. A little CYA: To reiterate what has already been said, this workaround is not ideal and comes with some big caveats, so be sure to read through the thread and ask questions before implementing. I'm not going to get into it here, but I used S1dney's same basic directions for the docker by making backups and copying files to folders in /boot/config/. Create a share called libvirt on the cache drive just like for the docker instructions. edit rc.libvirt 's start_libvirtd method as follows: start_libvirtd() { if [ -f $LIBVIRTD_PIDFILE ];then echo "libvirt is already running..." exit 1 fi if mountpoint /etc/libvirt &> /dev/null ; then echo "Image is mounted, will attempt to unmount it next." umount /etc/libvirt 1>/dev/null 2>&1 if [[ $? -ne 0 ]]; then echo "Image still mounted at /etc/libvirt, cancelling cause this needs to be a symlink!" exit 1 else echo "Image unmounted succesfully." fi fi # In order to have a soft link created, we need to remove the /etc/libvirt directory or creating a soft link will fail if [[ -d /etc/libvirt ]]; then echo "libvirt directory still exists, removing it so we can use it for the soft link." rm -rf /etc/libvirt if [[ -d /etc/libvirt ]]; then echo "/etc/libvirt still exists! Creating a soft link will fail thus refusing to start libvirt." exit 1 else echo "Removed /etc/libvirt. Moving on." fi fi # Now that we know that the libvirt image isn't mounted, we want to make sure the symlink is active if [[ -L /etc/libvirt && -d /etc/libvirt ]]; then echo "/etc/libvirt is a soft link, libvirt is allowed to start" else echo "/etc/libvirt is not a soft link, will try to create it." ln -s /mnt/cache/libvirt /etc/ 1>/dev/null 2>&1 if [[ $? -ne 0 ]]; then echo "Soft link could not be created, refusing to start libvirt!" exit 1 else echo "Soft link created." fi fi # convert libvirt 1.3.1 w/ eric's hyperv vendor id patch to how libvirt does it in libvirt 1.3.3+ sed -i -e "s/<vendor id='none'\/>/<vendor_id state='on' value='none'\/>/g" /etc/libvirt/qemu/*.xml &> /dev/null # remove <locked/> from xml because libvirt + virlogd + virlockd has an issue with locked sed -i -e "s/<locked\/>//g" /etc/libvirt/qemu/*.xml &> /dev/null # copy any new conf files we dont currently have cp -n /etc/libvirt-/*.conf /etc/libvirt &> /dev/null # add missing tss user account if coming from an older version of unRAID if ! grep -q "^tss:" /etc/passwd ; then useradd -r -c "Account used by the trousers package to sandbox the tcsd daemon" -d / -u 59 -g tss -s /bin/false tss fi echo "Starting libvirtd..." mkdir -p $(dirname $LIBVIRTD_PIDFILE) check_processor /sbin/modprobe -a $MODULE $MODULES /usr/sbin/libvirtd -d -l $LIBVIRTD_OPTS } Add this code the the go file in addition to the code for the docker workaround: # Put the modified libvirt service file over the original one to make it not use the libvirt.img cp /boot/config/service-mods/libvirt-service-mod/rc.libvirt /etc/rc.d/rc.libvirt chmod +x /etc/rc.d/rc.libvirt