[libvirt] [RFC PATCH 22/30] tests: qemublock: Add tests for all other format without special options

Kevin Wolf kwolf at redhat.com
Mon Apr 23 08:23:50 UTC 2018


Am 20.04.2018 um 21:20 hat Peter Krempa geschrieben:
> On Fri, Apr 20, 2018 at 13:55:35 +0200, Kevin Wolf wrote:
> > Am 19.04.2018 um 17:25 hat Peter Krempa geschrieben:
> > > Similarly to the 'raw' case add tests for bochs, cloop, dmg, ploop, vdi
> > > vhd, and vpc. Covering all supproted non-backing formats.
> > > 
> > > Note that the JSON name for 'ploop' maps to 'parallels' and 'vhd' maps
> > > to 'vhdx'.
> > 
> > Your -drive lines below mention format=ploop/vhd, though. That wouldn't
> > actually work.
> 
> So, is it something that we should actually forbid? I did not actually
> try all of the weird formats, so I just assumed that if we'd happily
> generate the -drive command line and the 'blockdev' version exists it's
> equivalent.

I thought it's just a mistake in the commit message and that libvirt
actually does the translation described here. So it would use -drive
format=parallels instead of ploop.

> > (Also 'vhd' as an alias for 'vhdx' is super confusing, because VHD is
> > really the name of the format implemented by QEMU's 'vpc' driver - which
> > is already a source of confusion on its own.)
> 
> Hmmm, maybe that is a bug in my implementation. Since libvirt has a VPC
> format and also a VHD format I thohght that VHD is just another name for
> 'vhxd'. If they are different, we maybe should forbid it altogether. I
> confess that I did a simple prefix match rather than any complex
> analysis.

Maybe double-check, but your assumption might be right. There would be
little reason to have both VPC and VHD, when both are names for the same
thing (except as aliases, possibly).

Kevin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20180423/234abab3/attachment-0001.sig>


More information about the libvir-list mailing list