Description of problem: When using virt-Manager to create a new virtual disk that which uses another disk as a backing store, it fails to detect the correct type of the backing store causing the created disk to not work as intended (i.e. it doesn't use the data in the backing store because it can not read the backing store). Version-Release number of selected component (if applicable): 1.2.1 How reproducible: Always Steps to Reproduce: 1. Create a disk with virt-manager and set the type to "qcow2" 2. (Optional, but very useful) Install a version of Linux on that disk. This will serve as a test to tell whether or not the backing_store operation was successful. 3. Create another new disk with virt-manager set the type to "qcow2" and set the backing_store to the first disk you created. 4. If you installed Linux on the first disk, attempt to boot it using the second. This *should* work since the second is a COW copy of the first. It will *not* work. 5. Use "qemu-img info <path to second disk>" to inspect the second disk. You will see something like the following ```` image: test.qcow2 file format: qcow2 virtual size: 8.0G (8589934592 bytes) disk size: 196K cluster_size: 65536 backing file: <path to first disk>.qcow2 backing file format: raw Format specific information: compat: 1.1 lazy refcounts: true refcount bits: 16 corrupt: false ```` Notice that the "backing file format" is set to "raw" not "qcow2". 6. To confirm this is really the issue, create a new "qcow2" disk with "qemu-img" directly using the following command "# qemu-img create -f qcow2 -o backing_file=<path to first disk>,backing_fmt=qcow2 grading.qcow2 100G" 7. Run "qemu-img info <path to new disk>" and you will see something like the following, ```` image: grading.qcow2 file format: qcow2 virtual size: 100G (107374182400 bytes) disk size: 500M cluster_size: 65536 backing file: <path to first disk>.qcow2 backing file format: qcow2 Format specific information: compat: 1.1 lazy refcounts: false refcount bits: 16 corrupt: false ```` Notice how "backing file format" is now correctly "qcow2" 8. If you installed Linux on the first disk, create a new VM on virt-manager, tell it to use the new (third) disk you just created using the "qemu-img create" command. This new VM will now boot and work normally. Actual results: virt-manager fails to detect format of the backing store when creating a new disk with a backing store. This causes the backing_store to be effectively ignored (strangely there are no explicit errors...it just acts like the other disk is empty) Expected results: virt-manager should detect the format of the backing store and set that appropriately when creating a disk with a backing store. Additional info: qemu-img version 2.3.0 I have only tested this with qcow2 disks. I can not say how this works with other disk types. I can only say that when you try to use qcow2 disks with a backing store in virt-manager the results are a broken disk.
Thanks for the report. Please attach virt-manager --debug output when reproducing the issue, namely specifying the backingstore for a new disk volume, attaching it to a VM/creating a VM, then starting the VM
Created attachment 1042805 [details] Output of virt-manager --debug with requested operations
Thanks. Yeah I think we just need to try to import the backing volume, so libvirt can tell us what format it is. Can you attach sudo virsh vol-dumpxml --pool default testBackingStore.qcow2 , just to confirm. note to self: when making this change, also log the XML after object creation. in fact we should do that when creating every object...
Created attachment 1042807 [details] XML for the testBackingStore.qcow2 image
Yeah that confirms it, libvirt just defaulting it to raw. So we will need to import the directory as a pool to determine the correct volume. We already have plumbing for that elsewhere so it shouldn't be too hard to wire up
This is still a useful addition to virt-manager. Is there any work being done on it? Thanks!
No one is actively working on it that I know of
I just found that the backing_store option of virt-install has the same problem. It prevents using virt-install as a one-liner for creating a vm with a backing_store.
Fixed upstream now: commit 5398282e12e12ac48dd10becea33456a483b7f5e Author: Cole Robinson <crobinso> Date: Thu Jun 16 20:36:30 2016 -0400 storage: Detect backing_store format automatically By attempting to manage/import the passed path. This makes it work via both virt-install and virt-manager https://bugzilla.redhat.com/show_bug.cgi?id=1235406