Does it make sense to expose somewhat the different types of disk images which
you can create to use with a guest? While PV guests currently won't work with
anything other than just raw images, that needs fixing anyway... and FV/qemu
can work nicely with things like qcow/qcow2/vmdk. And that makes preallocate vs
not just sparse vs preallocated raw image.
change QA contact
Dan has already explicity rejected anything exposing the underlying storage
driver in virt-manager. With the libvirt storage api integration on the horizon
though I don't know if this will change. Dan?
When the storage UI in virt-manager is re-written to support the libvirt storage
API, we will expose the full range of disk formats including qcow/vmdk, etc, so
we should keep this open till that's done.
*** Bug 370161 has been marked as a duplicate of this bug. ***
Adding FutureFeature keyword to RFE's.
Current upstream now allows provisioning more complex storage (file formats included) on demand via the libvirt storage file browser. Moving to POST.
This is in rawhide as of virt-manager-0.7.0-1. Closing as RAWHIDE.