Seems there is no formal report for this:
Just encountered it on current 6.11.5.
- Stop VM service
- Start it again
- You get something like
Dec 19 21:13:20 Unraid emhttpd: shcmd (1167849): /usr/local/sbin/mount_image '/mnt/user/system/libvirt/libvirt.img' /etc/libvirt 1
Dec 19 21:13:20 Unraid root: '/mnt/user/system/libvirt/libvirt.img' is in-use, cannot mount
mount shows no references to libvirt.img.
Mounting libvirt.img to a random folder works fine. Unmounting too.
fuser -c /mnt/user/system/libvirt/libvirt.img shows a myriad of PIDs "accessing" it, such as nginx and dockers. Makes no sense.
root@Unraid:~# fuser -c /mnt/cache/system/libvirt/libvirt.img
/mnt/cache/system/libvirt/libvirt.img: 13453 14543 14579 14580 14581 14582 16212m 16865 17523 17747 17783 19345c 21127 21298 21992 23274 23281m 23520 23675e 23689e 23761e 23776e 23798e 24009m 24046m 24080 24433m 25326cm 25778 25957c 25958c 27660c 28428m 28797c 28803 28804 28806 28807 28808 28810 28811 28812 28814 29204c 29205c 29206c 29207c 29208c 29209c 29210c 29211c 29212c 29213c 29223c 29224c 29225c 29226c 29227c 29229c 29234c 29235c 29639 29770cm 30774cm 30966c 31536c 32015 32036 32710
losetup -d /dev/[what libvirt is mounted at] does nothing, it remains present in losetup output
root@Unraid:~# losetup
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop1 0 0 1 1 /boot/bzmodules 0 512
/dev/loop2 0 0 1 0 /mnt/cache/system/docker/docker.img 1 512
/dev/loop0 0 0 1 1 /boot/bzfirmware 0 512
/dev/loop3 0 0 1 0 /mnt/cache/system/libvirt/libvirt.img 1 512
Trying to mount manually to usual location manually works:
mount /mnt/cache/system/libvirt/libvirt.img /etc/libvirt
[something new]
ls -l /etc shows a "libvirt-" folder and the contents of that still reflect the image contents, but no idea how to get rid of that. It's not a mount
root@Unraid:/etc/libvirt-# ls
hooks/ nwfilter/ secrets/ virtinterfaced.conf virtnodedevd.conf virtsecretd.conf
libvirt-admin.conf qemu/ storage/ virtlockd.conf virtnwfilterd.conf virtstoraged.conf
libvirt.conf qemu-lockd.conf virt-login-shell.conf virtlogd.conf virtproxyd.conf
libvirtd.conf qemu.conf virtchd.conf virtnetworkd.conf virtqemud.conf
root@Unraid:/etc# umount /etc/libvirt-/
umount: /etc/libvirt-/: not mounted.
root@Unraid:/etc# umount /mnt/user/system/libvirt/libvirt.img
umount: /mnt/user/system/libvirt/libvirt.img: not mounted.
root@Unraid:/etc# umount /mnt/cache/system/libvirt/libvirt.img
umount: /mnt/cache/system/libvirt/libvirt.img: not mounted.
I've followed the path and found /usr/local/sbin/mount_image responsible for mounting the image. It makes a check with /usr/local/sbin/in_use for whether the image is in use. That does an losetup -j "$FILE" that returns it's /dev/loop3 as seen above, so the mount aborts.
I've tried going "raw" and simply commenting out the abort in mount_image:
# check that the file is not already in-use (or being moved by 'mover')
if /usr/local/sbin/in_use "$FILEPATH" ; then
echo "'$FILEPATH' is in-use, cannot mount"
# exit 1
The service will start happily, VMs run, nothing goes wrong, there isn't an extra loop device created or anything.
Got nowhere trying to find what could be "accessing" the file and causing the whole thing or what this "libvirt-" folder is, that might be the source?
If it helps my system is currently fully usable thanks to the workaround but allows for reproducing the issue if that's reverted, loop3 will just never disappear.
Recommended Comments
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.