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, 20197 yr by johnsanc

Not reproducible, please test with system started in safe mode.

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, 20197 yr by johnsanc

Please delete "ncurses-5.9-x86_64-2.txz" from the /extra folder on your flash device.

Reboot and retest.

Done, but still the same issue

Any other suggestions for this? Is there a process for starting clean and restoring VMs / Dockers / etc?

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, 20197 yr by bonienl

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, 20197 yr by johnsanc

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.

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.

Does your "system" folder exist only on cache or multiple places?

cache only share... just checked all drives and the system folder only exists on the cache pool.

Edited May 19, 20197 yr by johnsanc

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?

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, 20197 yr by johnsanc

Please post new diagnostics

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, 20197 yr by johnsanc

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?

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, 20197 yr by johnsanc

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.

 

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, 20197 yr by bonienl

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, 20197 yr by johnsanc

You can safely delete the folder "dynamix.kvm.manager", this is deprecated.

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, 20197 yr by johnsanc

Unraid 6 uses "dynamix.vm.manager"

Can't remember about virtMan, but surely isn't used by stock Unraid.

 

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.