johnsanc Posted May 13, 2019 Share Posted May 13, 2019 (edited) 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.) Edited May 13, 2019 by johnsanc Quote Link to comment
bonienl Posted May 13, 2019 Share Posted May 13, 2019 Not reproducible, please test with system started in safe mode. Quote Link to comment
johnsanc Posted May 13, 2019 Author Share Posted May 13, 2019 (edited) 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 Edited May 13, 2019 by johnsanc Quote Link to comment
bonienl Posted May 13, 2019 Share Posted May 13, 2019 Please delete "ncurses-5.9-x86_64-2.txz" from the /extra folder on your flash device. Reboot and retest. Quote Link to comment
johnsanc Posted May 13, 2019 Author Share Posted May 13, 2019 Done, but still the same issue Quote Link to comment
johnsanc Posted May 18, 2019 Author Share Posted May 18, 2019 Any other suggestions for this? Is there a process for starting clean and restoring VMs / Dockers / etc? Quote Link to comment
bonienl Posted May 19, 2019 Share Posted May 19, 2019 (edited) 16 hours ago, johnsanc said: Any other suggestions for this? Is there a process for starting clean and restoring VMs / Dockers / etc? Stop your VM service and delete and recreate the image, this lets you start with a new (empty) set up. When creating your VMs, you can either point to the existing vdisk, or start fresh. Edited May 19, 2019 by bonienl Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 (edited) 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 Edited May 19, 2019 by johnsanc Quote Link to comment
bonienl Posted May 19, 2019 Share Posted May 19, 2019 Do you have a cache device? Create the VM image directly on the cache device (/mnt/cache/system/libvirt.img) instead of using the unassigned devices plugin. Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 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. Quote Link to comment
bonienl Posted May 19, 2019 Share Posted May 19, 2019 Does your "system" folder exist only on cache or multiple places? Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 (edited) cache only share... just checked all drives and the system folder only exists on the cache pool. Edited May 19, 2019 by johnsanc Quote Link to comment
bonienl Posted May 19, 2019 Share Posted May 19, 2019 Try to change the reference of the image from '/mnt/user/system/libvirt/libvirt.img' to '/mnt/cache/system/libvirt/libvirt.img' (see Settings -> VM Manager) Can you also post diagnostics? Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 (edited) 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? Edited May 19, 2019 by johnsanc Quote Link to comment
bonienl Posted May 19, 2019 Share Posted May 19, 2019 Please post new diagnostics Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 (edited) 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 Edited May 19, 2019 by johnsanc Quote Link to comment
bonienl Posted May 19, 2019 Share Posted May 19, 2019 When you delete the image (under VM manager) all the XML files are gone. They exist inside the image. You sure you deleted the existing image and create a new empty one? Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 (edited) 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. Edited May 19, 2019 by johnsanc Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 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. Quote Link to comment
bonienl Posted May 19, 2019 Share Posted May 19, 2019 (edited) Try to delete and recreate the VM image while in safe mode. See if this makes a difference. Also to be an the safe side, comment out this statement in your go file # Install packages. # cd /boot/packages && find . -name '*.auto_install' -type f -print | sort | xargs -n1 sh -c Edited May 19, 2019 by bonienl Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 (edited) 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. Edited May 19, 2019 by johnsanc Quote Link to comment
bonienl Posted May 19, 2019 Share Posted May 19, 2019 You can safely delete the folder "dynamix.kvm.manager", this is deprecated. Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 (edited) 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 Edited May 19, 2019 by johnsanc Quote Link to comment
bonienl Posted May 19, 2019 Share Posted May 19, 2019 Unraid 6 uses "dynamix.vm.manager" Can't remember about virtMan, but surely isn't used by stock Unraid. Quote Link to comment
johnsanc Posted May 19, 2019 Author Share Posted May 19, 2019 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. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.