Description of problem: I create my virtual disks using base images to avoid having to re-install from scratch. If I use virt-manager functionality for this the OS (mainly windows operating systems) will not boot so I am forced to use qemu-img utility to create based disks. This has become handy over time and I have created scripts that will allow me to create virtual machines based on templates and base disks. When I create a disk that has a qcow2 disk as base, virt-manager does not show it on the disk pool and when editing a vitrual machine I get the following error: Error refreshing hardware page: cannot stat file 'Windows-2008R2-sp2010.qcow2': No such file or directory However the image can been seem in virsh with command 'virsh vol-list VMs': Name Path ------------------------------------------------------------------------------ arch-linux.qcow2 /mnt/storage/VMs/arch-linux.qcow2 Windows-2008R2-JP.qcow2 /mnt/storage/VMs/Windows-2008R2-JP.qcow2 Windows-2008R2-sp2010.qcow2 /mnt/storage/VMs/Windows-2008R2-sp2010.qcow2 Windows-2008R2.qcow2 /mnt/storage/VMs/Windows-2008R2.qcow2 Windows-2010-dev.qcow2 /mnt/storage/VMs/Windows-2010-dev.qcow2 Windows-Core-2.qcow2 /mnt/storage/VMs/Windows-Core-2.qcow2 Windows-Core.qcow2 /mnt/storage/VMs/Windows-Core.qcow2 The image Windows-2008R2-sp2010.qcow2 is the base image for Windows-2010-dev.qcow2. In the attachment you can see the images that are visible in virt-manager. Version-Release number of selected component (if applicable): How reproducible: I can reproduce it all the time by using the steps below. Steps to Reproduce: 1. Create a virtual disk using format qcow2 as base (e.g. my-base-disk.qcow2) 2. Create a new virtual disk using qemu-img having as base the disk created at step 1. (qemu-img create -f qcow2 -b my-base-disk.qcow2 awesome-disk.qcow2) 3. Refresh virsh disk pool 4. Open virt-manager and navigate to disk pool check if it exists 5. OPTIONAL: move the disk from step 2 into a new disk pool and observe the same behavior in virt-manager and virsh Actual results: The disk created in step 2 is missing from the list of disks in the disk pool Expected results: The same disks that are visible in the vol list in virsh should be visible and usable by virt-manager Additional info:
Created attachment 914361 [details] virt-manager disk pool
what does virsh vol-list show with --details? virsh vol-list --details $POOL_NAME
a followup to my previous comment: does "qemu-img create -f qcow2 -b $(pwd)/my-base-disk.qcow2 awesome-disk.qcow2" make any difference in the virt-manager behavior?
Tunning virsh vol-list VMs --details gave the following output: Name Path Type Capacity Allocation ----------------------------------------------------------------------------------------------------------- arch-linux.qcow2 /mnt/storage/VMs/arch-linux.qcow2 file 16.00 GiB 2.70 MiB Windows-2008R2-JP.qcow2 /mnt/storage/VMs/Windows-2008R2-JP.qcow2 file 80.00 GiB 14.86 GiB Windows-2008R2-sp2010.qcow2 /mnt/storage/VMs/Windows-2008R2-sp2010.qcow2 file 80.00 GiB 18.89 GiB Windows-2008R2.qcow2 /mnt/storage/VMs/Windows-2008R2.qcow2 file 80.00 GiB 14.71 GiB Windows-2010-dev.qcow2 /mnt/storage/VMs/Windows-2010-dev.qcow2 unknown unknown unknown Windows-Core-2.qcow2 /mnt/storage/VMs/Windows-Core-2.qcow2 file 50.01 GiB 1.68 GiB Windows-Core.qcow2 /mnt/storage/VMs/Windows-Core.qcow2 file 50.01 GiB 16.94 GiB Running qemu-img info Windows-2010-dev.qcow2 gave the follwoing output: image: Windows-2010-dev.qcow2 file format: qcow2 virtual size: 80G (85899345920 bytes) disk size: 17G cluster_size: 65536 backing file: Windows-2008R2-sp2010.qcow2 Format specific information: compat: 1.1 lazy refcounts: false Seeing your second comment I decided to rebase the image that has unknown type and size; so I ran qemu-img rebase -f qcow2 -u -b $(pwd)/Windows-2008R2-sp2010.qcow2 Windows-2010-dev.qcow2 Now, running qemu-img info Windows-2010-dev.qcow2 outputs: image: Windows-2010-dev.qcow2 file format: qcow2 virtual size: 80G (85899345920 bytes) disk size: 17G cluster_size: 65536 backing file: /mnt/storage/VMs/Windows-2008R2-sp2010.qcow2 Format specific information: compat: 1.1 lazy refcounts: false This seems the same, only that the backing file now has a full path instead of a relative path. Running virsh vol-list VMs --details again seems to be OK: Name Path Type Capacity Allocation ----------------------------------------------------------------------------------------------------------- arch-linux.qcow2 /mnt/storage/VMs/arch-linux.qcow2 file 16.00 GiB 2.70 MiB Windows-2008R2-JP.qcow2 /mnt/storage/VMs/Windows-2008R2-JP.qcow2 file 80.00 GiB 14.86 GiB Windows-2008R2-sp2010.qcow2 /mnt/storage/VMs/Windows-2008R2-sp2010.qcow2 file 80.00 GiB 18.89 GiB Windows-2008R2.qcow2 /mnt/storage/VMs/Windows-2008R2.qcow2 file 80.00 GiB 14.71 GiB Windows-2010-dev.qcow2 /mnt/storage/VMs/Windows-2010-dev.qcow2 unknown unknown unknown Windows-Core-2.qcow2 /mnt/storage/VMs/Windows-Core-2.qcow2 file 50.01 GiB 1.68 GiB Windows-Core.qcow2 /mnt/storage/VMs/Windows-Core.qcow2 file 50.01 GiB 16.94 GiB Also, virt-manager now does not complain anymore about the image. I must say that I assumed that the relative paths will be the pool path, but it seems that this is not the case. I think that the issue can be closed, it is more of a documentation issue than functionality. Now to rebase all my images :) Thanks for the help!