On Mon, Feb 11, 2019 at 07:14:26AM -0500, John Ferlan wrote: > > > On 2/11/19 6:12 AM, Daniel P. Berrangé wrote: > > On Mon, Feb 11, 2019 at 06:10:38AM -0500, Laine Stump wrote: > >> On Mon, Feb 11, 2019, 5:47 AM Daniel P. Berrangé <berrange@xxxxxxxxxx> > >> wrote: > >> > >>> On Thu, Feb 07, 2019 at 10:08:28PM -0500, Laine Stump wrote: > >>>> RHEL8 has dropped support for qcow1 format images, so skip the tests > >>>> related to creating/cloning qcow1 images (based on the output of > >>>> qemu-img -help). > >>>> > >>>> Signed-off-by: Laine Stump <laine@xxxxxxxxx> > >>>> --- > >>>> scripts/storage/100-create-vol-dir.t | 22 ++++++++----- > >>>> scripts/storage/200-clone-vol-dir.t | 48 ++++++++++++++++------------ > >>>> 2 files changed, 41 insertions(+), 29 deletions(-) > >>> > >>> Reviewed-by: Daniel P. Berrangé <berrange@xxxxxxxxxx> > >>> > >>> > >>> This is an example where libvirt storage pool capabilities would be > >>> useful. > >>> > > Current working code I have (unreviewed) has: > > <storagepoolCapabilities> > ... > <pool type='fs' supported='yes'> > <poolOptions> > <defaultFormat type='auto'/> > <enum name='sourceFormatType'> > <value>auto</value> > <value>ext2</value> > <value>ext3</value> > <value>ext4</value> > <value>ufs</value> > <value>iso9660</value> > <value>udf</value> > <value>gfs</value> > <value>gfs2</value> > <value>vfat</value> > <value>hfs+</value> > <value>xfs</value> > <value>ocfs2</value> > </enum> > <enum name='requiredSourceElements'> > <value>device</value> > </enum> > </poolOptions> > <volOptions> > <defaultFormat type='raw'/> > <enum name='targetFormatType'> > <value>none</value> > <value>raw</value> > <value>dir</value> > <value>bochs</value> > <value>cloop</value> > <value>dmg</value> > <value>iso</value> > <value>vpc</value> > <value>vdi</value> > <value>fat</value> > <value>vhd</value> > <value>ploop</value> > <value>cow</value> > <value>qcow</value> > <value>qcow2</value> > <value>qed</value> > <value>vmdk</value> > </enum> > </volOptions> > </pool> > ... > </storagepoolCapabilities> > > >> > >> Yeah, or maybe listing the supported types in the device capabilities for > >> the disks. I had meant to point that out but forgot. > > > > We would need both, because QEMU has a setup where qemu-img can support a > > disk format while qemu-system-XXX will not support it. This is so that > > we can limit what is usable at runtime, but still have qemu-img for data > > liberation from old format images. > > So, would this be something formatted from src/util/virstoragefile.c > FileTypeInfo for a specific $path then? Or more generically from > qemu-img like I assume this patch does? IIRC -help scraping has been > removed and the "hope" was some day some sort of capabilities type > approach would be used. Been a while since I've thought about it though. I meant that the "dom capabilities" XML needs to report supported block driver formats separately from "storage capabilities". This isn't related to specific disk image paths, it is a property of the QEMU binaries. Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
