Jump to content

johnsanc

Members
  • Content Count

    129
  • Joined

  • Last visited

Everything posted by johnsanc

  1. Sounds good, thanks again for all your help with this. I'm glad it was actually something very simple, albeit a little tricky to find.
  2. I found a resolution to the issue I posted here and earlier in this thread if DEBUG is set to "yes" in the domain.cfg then the VMs UI will choke and appears to load forever. Changing this to "no" solved the issue. Still not really sure how that was ever set to "yes" in the first place though... just thought I would share in case anyone else runs into this.
  3. I FIGURED IT OUT!!! For some reason in my domain.cfg I had DEBUG set to "yes" - I have no idea how this even gets set to "yes" since I dont see anything for that in the webUI. I manually changed this to "no" and it worked. Not sure why that debug flag would cause the WebUI to choke, but at least I figured out the issue. Maybe thats something easy to fix with the next update. SERVICE="enable" IMAGE_FILE="/mnt/user/system/libvirt/libvirt.img" IMAGE_SIZE="1" DEBUG="yes" DOMAINDIR="/mnt/user/domains/vm/" MEDIADIR="/mnt/user/domains/iso/" VIRTIOISO="/mnt/user/domains/iso/virtio-win-0.1.160-1.iso" BRNAME="virbr0" VMSTORAGEMODE="auto" DISKDIR="/mnt/" TIMEOUT="60" HOSTSHUTDOWN="shutdown" (Restored my flash backup because the clean install was going to be an even bigger headache...)
  4. I was finally able to get it to work with stock .cfgs that were auto-generated with the exception of the disks cfg. I added that in so I could at least get to the VMs screen. - Although something is wrong with my cache devices. It did not recreate my cache pool properly. I think there is a defect in the VMs portion of the webGUI code. Also, if I start fresh with just the key and super.dat shouldn't it have assigned my cache drives properly? They are both populated as unassigned initially, which is a bit concerning.
  5. Yes its the same issue with all browsers across all devices I have, even in the unraid GUI mode browser. When I removed the .cfgs my cache drives are not included for some reason and so when I start the array the paths do not exist, so I cannot even get to the point where I can startup the VM service. I thought that including just the configs would be a good "bare minimum" - I'm not sure what else I can safely strip out.
  6. Ok, I STILL have the issue with the webUI even with a semi-virgin install. The only things I copied over were: super.dat Pro.key disk.cfg docker.cfg domain.cfg ident.cfg network-rules.cfg network.cfg share.cfg /shares/*.cfg Any thoughts?
  7. Alright, I guess I'll try that. I tried to downgrade then re-upgrade and I still got the same issues.
  8. Thanks, just read through all of it and I think I covered all of the cleanup (and then some) in the process of troubleshooting this issue. Still no luck. At this point I am not sure what else do.
  9. no luck - same issue in safe mode with all plugins disabled.
  10. Trying that now... even though there is no /boot/packages/ folder anyways
  11. Tried safe mode early on and it didn't make any difference it seems. How do I properly comment out package installation when going into safe mode?
  12. Deleted with no ill effects... getting closer, but I still get the WebUI error even after letting it create a new libvirt.img. But now the error is in a different place.
  13. Done... but now its auto-creating and pulling something even OLDER from when I had a windows 8.1 VM. Looks like this one is coming from the virtMan plugin... I assume this can be deleted too? (It would be really nice if Fix Common Problems flagged stuff like this) 2019-05-19 19:13:57.288+0000: 13583: info : libvirt version: 5.1.0 2019-05-19 19:13:57.288+0000: 13583: info : hostname: Tower 2019-05-19 19:13:57.288+0000: 13583: error : virStorageFileReportBrokenChain:4829 : Cannot access storage file '/mnt/disk/appdisk/vm/windows81pro/driver_image/virtio-win-0.1-94.iso': No such file or directory 2019-05-19 19:13:57.330+0000: 13583: error : qemuAutostartDomain:252 : internal error: Failed to autostart VM 'windows81pro': Cannot access storage file '/mnt/disk/appdisk/vm/windows81pro/driver_image/virtio-win-0.1-94.iso': No such file or directory 2019-05-19 19:14:08.780+0000: 13570: error : qemuOpenFileAs:3129 : Failed to open file '/mnt/disk/appdisk/vm/windows81pro/os_image/Win81AIO_With_Update-54in1-x64-en-US-Dec2014.iso': No such file or directory 2019-05-19 19:14:08.781+0000: 13572: error : qemuOpenFileAs:3129 : Failed to open file '/mnt/disk/appdisk/vm/windows81pro/driver_image/virtio-win-0.1-94.iso': No such file or directory 2019-05-19 19:14:08.782+0000: 13572: error : qemuOpenFileAs:3129 : Failed to open file '/mnt/disk/appdisk/vm/windows81pro/windows81pro.qcow2': No such file or directory
  14. I think I may have found the cuprit... I noticed this in the dynamix.kvm.manager plugin. Is this an old img file that is being restored automatically perhaps? I cracked open the domain.img directly and I do see references to those old paths that are no longer used. Is this plugin deprecated? Should I just remove it from the plugins folder? I see another one called dynamix.vm.manager but theres nothing in it.
  15. Also I see a similar issue here, but there was no resolution or explanation for the phantom XML being included immediately when the libvirt.img is created.
  16. I am absolutely positive. I tried moving it out of the folder AND I tried deleting in the webui. Its pulling this old info from somewhere, but I have NO idea where. I don't ever remember seeing anything like this prior to 6.7. Also, my "current" libvirt.img file references the correct windows10pro.xml... when i remove that img it creates a new image with an old XML from somewhere.
  17. OK I can see where these bad path references are coming from. When i wipe out my libvirt.img and start clean I can see there is an old version of my window10pro.xml within /etc/libvirt/qemu/ - Where the heck is this thing stored?! Still not sure if thats whats causing the issue, but its something I need to clean up anyways. [Diagnostics attached] tower-diagnostics-20190519-1830.zip
  18. Just tried it, same issue. I also checked both folders using midnight commander and I can see when i move the libvirt.img file out of that folder its moved when I look in both /user/ and /cache/... so I think the system folder is setup correctly. Diagnostics were posted above - Do you need new diagnostics?
  19. cache only share... just checked all drives and the system folder only exists on the cache pool.
  20. Yes, everything is on the cache drive now. Those references in the log were from like 2 years ago when I had all my VM stuff on unassigned devices. I have no idea where those references are coming from. They are not in the XML for that windows10pro VM that I currently use.
  21. This did not work. I still get the same issue. Upon recreating a fresh libvirt.img file I notice this in the libvirt logs... where is this coming from? Is it related to the webUI issue? These logs reference directories that have haven't been used in well over a year. 2019-05-19 17:00:25.551+0000: 30376: info : libvirt version: 5.1.0 2019-05-19 17:00:25.551+0000: 30376: info : hostname: Tower 2019-05-19 17:00:25.551+0000: 30376: error : qemuOpenFileAs:3129 : Failed to open file '/mnt/disks/vmdisk/iso/en_windows_10_multiple_editions_x64_dvd_6846432.iso': No such file or directory 2019-05-19 17:00:25.551+0000: 30379: error : qemuOpenFileAs:3129 : Failed to open file '/mnt/disks/vmdisk/drivers/virtio-win-0.1.110.iso': No such file or directory 2019-05-19 17:00:25.552+0000: 30379: error : qemuOpenFileAs:3129 : Failed to open file '/mnt/disks/vmdisk/vm/windows10pro/vdisk1.img': No such file or directory Also, I then tried to revert back to using my old libvirt.img file... after removing my newly created libvirt.img file and replacing again with my old one, the service will not start. Theres probably some easy explanation for that but this is what is in the log: May 19 13:11:45 Tower emhttpd: shcmd (340): /usr/local/sbin/mount_image '/mnt/user/system/libvirt/libvirt.img' /etc/libvirt 1 May 19 13:11:45 Tower root: /mnt/user/system/libvirt/libvirt.img is in-use, cannot mount May 19 13:11:45 Tower emhttpd: shcmd (340): exit status: 1
  22. Any other suggestions for this? Is there a process for starting clean and restoring VMs / Dockers / etc?
  23. Same issue across all browsers and devices in safe mode. I did notice that Firefox gives a slightly more descriptive console error: Diagnostics also attached. tower-diagnostics-20190513-1936.zip
  24. After upgrading to 6.7.0 my VMs tab of the webui continuously loads and I cannot manage any of my VMs. The VMs actually run just fine in the background, it's just the webui that is inoperable. I had no issues with 6.6.7. I get an unhandled exception error in the console: I also see that the /sub/var call is permanently pending... but I think that is intended for websockets: I tried rebooting, stopping and starting the VM service, backing up and deleting my libvirt.img and nothing has made a difference with the webui. Any ideas? (apologies for the double post - this issue got buried in the 6.7.0 announcement thread, if this belongs elsewhere please move it or let me know the right area to post.)