libvirt users - May 2010 - Cannot create qcow2 images with libvirt 0.8.1

Hi,

After upgrading to libvirt 0.8.1, I can no longer create empty volumes with no 
backing store and an explicit format of qcow2.

This XML volume definition:

<volume>
  <name>testserverb-data2.img</name>
  <allocation>0</allocation>
  <capacity units='G'>20</capacity>
  <target>
    <format type='qcow2'/>
    <permissions>
      <owner>107</owner>
      <group>107</group>
      <mode>0744</mode>
    </permissions>
  </target>
</volume>

yields the error "Cannot run /usr/bin/qemu-img to create /data/testserverb-
data.img: Invalid argument"

In /var/log/messages on the qemu host I can find the following snippet after 
that:

error : virRunWithHook:933 : internal error '/usr/bin/qemu-img create -f
qcow2
/data/testserverb-data.img 0K' exited with non-zero status 1 and signal 0: 
qemu-img: Image creation needs a size parameter#012
error : virStorageBackendCreateExecCommand:537 : Cannot run /usr/bin/qemu-img 
to create /data/testserverb-data.img: Invalid argument
error : qemudClientReadBuf:1653 : gnutls_record_recv: A TLS packet with 
unexpected length was received.

If I leave out the <format> element and/or specify a <backingStore>
element
for the volume, it works again. (I suppose the backing store makes it work 
because in that case qemu-img does not need a size parameter...)

The host system is a vanilla Fedora Core 12 system (aside from the upgraded 
libvirt).

Regards,

	Guido Winkelmann

Am Freitag, 28. Mai 2010 schrieb Guido Winkelmann:
> If I leave out the <format> element and/or specify a
<backingStore> element
> for the volume, it works again.
I have to correct myself:
If I leave out the format element, there will be an image created and there 
will be no error message, but the resulting image has a capacity of 0 bytes.

Regards

	Guido Winkelmann

On 05/28/2010 11:10 AM, Guido Winkelmann wrote:
> Hi,
> 
> After upgrading to libvirt 0.8.1, I can no longer create empty volumes with
no
> backing store and an explicit format of qcow2.
> 
> This XML volume definition:
> 
> <volume>
>   <name>testserverb-data2.img</name>
>   <allocation>0</allocation>
>   <capacity units='G'>20</capacity>
This should be 'unit', not 'units'. Libvirt is probably seeing
that as
20 bytes, rounding down to 0K, and qemu-img isn't happy.

- Cole
>   <target>
>     <format type='qcow2'/>
>     <permissions>
>       <owner>107</owner>
>       <group>107</group>
>       <mode>0744</mode>
>     </permissions>
>   </target>
> </volume>
> 
> yields the error "Cannot run /usr/bin/qemu-img to create
/data/testserverb-
> data.img: Invalid argument"
> 
> In /var/log/messages on the qemu host I can find the following snippet
after
> that:
> 
> error : virRunWithHook:933 : internal error '/usr/bin/qemu-img create
-f qcow2
> /data/testserverb-data.img 0K' exited with non-zero status 1 and signal
0:
> qemu-img: Image creation needs a size parameter#012
> error : virStorageBackendCreateExecCommand:537 : Cannot run
/usr/bin/qemu-img
> to create /data/testserverb-data.img: Invalid argument
> error : qemudClientReadBuf:1653 : gnutls_record_recv: A TLS packet with 
> unexpected length was received.
> 
> If I leave out the <format> element and/or specify a
<backingStore> element
> for the volume, it works again. (I suppose the backing store makes it work 
> because in that case qemu-img does not need a size parameter...)
> 
> The host system is a vanilla Fedora Core 12 system (aside from the upgraded
> libvirt).
> 
> Regards,
> 
> 	Guido Winkelmann
> 
> _______________________________________________
> libvirt-users mailing list
> libvirt-users at redhat.com
> https://www.redhat.com/mailman/listinfo/libvirt-users