Bug 1854365 - No check on '/var/lib/libvirt/images' directory
Summary: No check on '/var/lib/libvirt/images' directory
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Virtualization Tools
Classification: Community
Component: virt-manager
Version: unspecified
Hardware: Unspecified
OS: Linux
unspecified
low
Target Milestone: ---
Assignee: Cole Robinson
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-07-07 09:51 UTC by frodgesh
Modified: 2023-08-05 20:54 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-08-31 19:39:12 UTC
Embargoed:


Attachments (Terms of Use)

Description frodgesh 2020-07-07 09:51:32 UTC
Uncaught error validating install parameters: cannot open directory '/var/lib/libvirt/images': No such file or directory

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/createvm.py", line 1465, in _validate
    return self._validate_storage_page()
  File "/usr/share/virt-manager/virtManager/createvm.py", line 1733, in _validate_storage_page
    path, path_already_created = self._get_storage_path(
  File "/usr/share/virt-manager/virtManager/createvm.py", line 1726, in _get_storage_path
    path = self._addstorage.get_default_path(vmname)
  File "/usr/share/virt-manager/virtManager/device/addstorage.py", line 155, in get_default_path
    path = virtinst.StorageVolume.find_free_name(
  File "/usr/share/virt-manager/virtinst/storage.py", line 464, in find_free_name
    StoragePool.ensure_pool_is_running(pool_object, refresh=True)
  File "/usr/share/virt-manager/virtinst/storage.py", line 209, in ensure_pool_is_running
    pool_object.refresh(0)
  File "/usr/lib/python3/dist-packages/libvirt.py", line 3634, in refresh
    if ret == -1: raise libvirtError ('virStoragePoolRefresh() failed', pool=self)
libvirt.libvirtError: cannot open directory '/var/lib/libvirt/images': No such file or directory

Comment 1 Cole Robinson 2020-08-31 19:39:12 UTC
Thanks for the report, but things are more subtle than that.

When virt-manager is first run it checks to see if there's a libvirt storage pool named 'default' defined. If not, it creates one pointing to /var/lib/libvirt/images. If the directory did not exist at this point then it is created.

But once the 'default' pool is known to libvirt, we expect that it continues to exist on disk. If the directory is deleted behind virt-manager/libvirt's back, we don't attempt to recreate it. There's subtle reasons for this, like if the user configured the 'default' pool to point to a different type of storage, the 'build' command which does 'mkdir' for a simple directory case does other more destructive operations. Even for an existing directory, the build operation can change permissions from what the user set, so we can't unconditionally call the 'build' request for example.

We could fix this issue by checking for that specific error but IMO it's not worth it. Call 'sudo virsh pool-build default' yourself, or from virt-manager delete the pool and restart the app and it will create it again for you. Nothing in normal operation of the app should cause that directory to be deleted though so IMO I don't think it's anything we should try to code around


Note You need to log in before you can comment on or make changes to this bug.