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é <berra...@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 <la...@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é <berra...@redhat.com>
This is an example where libvirt storage pool capabilities would be
useful.
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.
Now that you mention that, I'm surprised that's not the case with RHEL8
and qcow1 - qemu-img doesn't support it. Maybe they got a bit
over-zealous when deprecating/removing qcow1 support.
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
