qcow2 version woes

[Mike Ruckman]

Fellow cloudies,

The recent builds of our images are v3 qcow2 (also known as qcow3). This
presents a problem for our testing, since the openstack instances we
have access to don't support v3, only v2. The only difference between v2
and v3 are some performance enhancements - so the question is, should we
produce v2 images instead of v3 for easier testing?

This would require us to request a tweak from releng to get the correct
format, but would stop us from having to use a workaround [0] to test
(and I worry about testing a converted image - because then we rely on
"well, it *should* be the same" for our test results). 

Thoughts?

[0] qemu-img amend -f qcow2 -o compat=0.10 <image.qcow2>

-- 
// Mike 
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org

[Dennis Gilmore]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 5 Mar 2015 11:48:08 -0700
Mike Ruckman <roshi(a)fedoraproject.org&gt; wrote:

>  Fellow cloudies,
>  
>  The recent builds of our images are v3 qcow2 (also known as qcow3).
>  This presents a problem for our testing, since the openstack
>  instances we have access to don't support v3, only v2. The only
>  difference between v2 and v3 are some performance enhancements - so
>  the question is, should we produce v2 images instead of v3 for easier
>  testing?
>  
>  This would require us to request a tweak from releng to get the
>  correct format, but would stop us from having to use a workaround [0]
>  to test (and I worry about testing a converted image - because then
>  we rely on "well, it *should* be the same" for our test results). 
>  
>  Thoughts?
>  
>  [0] qemu-img amend -f qcow2 -o compat=0.10 <image.qcow2>
>  
>  
it would require patching in koji, we require that the tools create the
correct thing and do not do manipulation after.

Dennis
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQIcBAEBAgAGBQJU+KiiAAoJEH7ltONmPFDRTgwQAJjDWKDwHAL+Q5cpBfzuWk5r
> FLlAv+ge10Br92C9d1e0ihrdD4HLIfkCX9qITs4eWk9ppHCIEJ+BqTdFYvEDQQF6
> pF/B7gDNvI93nAVNfZ7JVmt8TQZ9UhiIeJrzeSBIx3QXPvpY8lEso2WOMsBHs4ZK
> RPh19GYZPuFwPWcPZGoJK3ZCXwbOqibaGjrE5OW6GTjziBW8EfIylN7UGEvE2TJo
> h7uHgtWL32MnvhU9YH+rnul6QVldH+kCwYL+2ZRDuzy0laQsTKMZLwyEv2n7qycI
> 0OEkZpLWtbgsLxFhr7GqQ7cyV4CUS86KKoll4bYK5+DcSmJxim79gHb7Wyt2BE2F
> /QrBe7ew+sOE9Q6qHMWNQApmWPiQtj6X1VrSp0NGuFQULgtb9tYUbFCda+YYvfKy
> N6SO5xvFjSg4lzOvazgzqrT5l4SVNnEL3OkddLmswkwz5sxIspJfezFNYtSOHxhJ
> PVkt49qLnp0HElOTICvD0S7CvR81z3kYfm4oAnlxdSHPymIqGTHKpmkmRx0LxUk3
> xdCO6kSl62AA1wiwyteBfUj0IDPLyTYFeD9wsr+/EFGLtaXYsoZDsgtSIEwWxAl3
> Knt3hC6vx4wzzxn0LyXMVUN3hESlVgqG+5qXztzyo0+8Ym88ytmc3dL4itq9phI7
> D8mycgLuwzrwx4soai8l
> =Bi7F
> -----END PGP SIGNATURE-----
>

[Colin Walters]

On Thu, Mar 5, 2015, at 01:48 PM, Mike Ruckman wrote:

>  [0] qemu-img amend -f qcow2 -o compat=0.10 <image.qcow2>
See
https://github.com/redhat-imaging/imagefactory/commit/7434c9e7506d5896508...

A version of ImageFactory with this commit just needs to be deployed.

[Kashyap Chamarthy]

On Thu, Mar 05, 2015 at 11:48:08AM -0700, Mike Ruckman wrote:
>  Fellow cloudies,
>  
>  The recent builds of our images are v3 qcow2 (also known as qcow3).
>  This presents a problem for our testing, since the openstack instances
>  we have access to don't support v3, only v2. The only difference
>  between v2 and v3 are some performance enhancements - 
Right, just some details on the said performance enhancements in QCOW2
v3 format, from my notes (about a year old) from an earlier discussion
w/ some QEMU developers, the two new features in v3 of QCOW2:

  (1) lazy_refcounts -- A performance optimization interesting only when
  using 'cache=writethrough'. Useful when guest crashes or powers off.
  
  (2) Zero clusters -- Useful for (disk) image streaming over slow
  networks.

>  so the question is, should we produce v2 images instead of v3 for
>  easier testing? 
 
>  This would require us to request a tweak from releng to get the
>  correct format, but would stop us from having to use a workaround [0]
>  to test (and I worry about testing a converted image - because then we
>  rely on "well, it *should* be the same" for our test results). 
>  
>  Thoughts?
>  
>  [0] qemu-img amend -f qcow2 -o compat=0.10 <image.qcow2> 
-- 
/kashyap

[Mo Morsi]

On 03/06/2015 12:00 PM, Kashyap Chamarthy wrote:
>  On Thu, Mar 05, 2015 at 11:48:08AM -0700, Mike Ruckman wrote:
> > Fellow cloudies,
> >
> > The recent builds of our images are v3 qcow2 (also known as qcow3).
> > This presents a problem for our testing, since the openstack instances
> > we have access to don't support v3, only v2. The only difference
> > between v2 and v3 are some performance enhancements -
>  Right, just some details on the said performance enhancements in QCOW2
>  v3 format, from my notes (about a year old) from an earlier discussion
>  w/ some QEMU developers, the two new features in v3 of QCOW2:
>
>     (1) lazy_refcounts -- A performance optimization interesting only when
>     using 'cache=writethrough'. Useful when guest crashes or powers off.
>     
>     (2) Zero clusters -- Useful for (disk) image streaming over slow
>     networks.
>
>  
Perhaps of interest:

http://talk.manageiq.org/t/qcow-image-format-versions-2-3-analysis/491

   -Mo

[Kashyap Chamarthy]

On Fri, Mar 06, 2015 at 03:48:40PM -0500, Mo Morsi wrote:
>  
>  On 03/06/2015 12:00 PM, Kashyap Chamarthy wrote:
>  >On Thu, Mar 05, 2015 at 11:48:08AM -0700, Mike Ruckman wrote:
>  >>Fellow cloudies,
>  >>
>  >>The recent builds of our images are v3 qcow2 (also known as qcow3).
>  >>This presents a problem for our testing, since the openstack instances
>  >>we have access to don't support v3, only v2. The only difference
>  >>between v2 and v3 are some performance enhancements -
>  >Right, just some details on the said performance enhancements in QCOW2
>  >v3 format, from my notes (about a year old) from an earlier discussion
>  >w/ some QEMU developers, the two new features in v3 of QCOW2:
>  >
>  >   (1) lazy_refcounts -- A performance optimization interesting only when
>  >   using 'cache=writethrough'. Useful when guest crashes or powers off.
>  >   (2) Zero clusters -- Useful for (disk) image streaming over slow
>  >   networks.
>  >
>  >
>  
>  Perhaps of interest:
>  
>  http://talk.manageiq.org/t/qcow-image-format-versions-2-3-analysis/491 
Yep, it is interesting.

Thanks for the pointer, Mo.

-- 
/kashyap