Re: [libvirt] [tck PATCH 1/4] storage: skip qcow1 tests when qcow1 isn't supported by qemu-img

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(a)redhat.com&gt; >> 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(a)laine.org&gt; >>>> --- >>>> 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(a)redhat.com&gt; >>> >>> >>> 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.