Description of problem: As you remember, according to new qemu approach we need to use 'host_device' as volume format during creation preallocate volume on block device. But, after that I can create snapshot from this volume when I send 'raw' format as backing-file format to qemu-img (I can do it also with 'host_device' format as backing-file format). So, I think we have some inconsistency here. If we decided to use 'host_device' as format option for preallocate block volume we shouldn't allow create snapshots of this volume with backing-file format 'raw' Version-Release number of selected component (if applicable): How reproducible: > qemu-img create -f host_device /dev/16430fb2-c720-4581-9632-a77f9aa804e5/1234 100M Formatting '/dev/16430fb2-c720-4581-9632-a77f9aa804e5/1234', fmt=host_device, size=102400 kB > qemu-img create -f qcow2 -F raw -b /dev/16430fb2-c720-4581-9632-a77f9aa804e5/1234 /dev/16430fb2-c720-4581-9632-a77f9aa804e5/3456 Formatting '/dev/16430fb2-c720-4581-9632-a77f9aa804e5/3456', fmt=qcow2, backing_file=/dev/16430fb2-c720-4581-9632-a77f9aa804e5/1234, backing_fmt=raw, size=1048576 kB Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
So what you are requesting is that opening a host device as raw should fail? I agree that there is some inconsistency, but is this really a problem that needs to be addressed in RHEL 5 instead of being resolved upstream? If I understand it right this doesn't cause breakage but just means that something additional works that strictly speaking shouldn't be working in this version.
You understood perfectly well and seeing as we do not use this path at all then there is no reason to do this upstream or not at all, as you see fit.
Hi Kevin, You right it doesn't break anything. I mentioned above that IMHO it just inconsistency.
The related discussion took place in bug 537655. Behaviour is consistent again now that the fix for it is applied. Closing as a duplicate. *** This bug has been marked as a duplicate of bug 537655 ***