[libvirt] [tck PATCH 1/4] storage: skip qcow1 tests when qcow1 isn't supported by qemu-img
Daniel P. Berrangé
berrange at redhat.com
Mon Feb 11 13:03:47 UTC 2019
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 at redhat.com>
> >> 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 at laine.org>
> >>>> ---
> >>>> 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 at redhat.com>
> >>>
> >>>
> >>> 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 :|
More information about the libvir-list
mailing list