On Wed, Mar 13, 2019 at 8:40 PM Jingjie Jiang <jingjie.jiang(a)oracle.com>
I had qcow2 on FC, but qemu-img still showed size is 0.
# qemu-img info
file format: qcow2
virtual size: 20G (21474836480 bytes)
*disk size: 0*
Format specific information:
lazy refcounts: false
refcount bits: 16
Is the behavior expected?
On 2/22/19 1:53 PM, Nir Soffer wrote:
On Fri, Feb 22, 2019 at 7:14 PM Nir Soffer <nsoffer(a)redhat.com> wrote:
> On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang <jingjie.jiang(a)oracle.com>
>> What about qcow2 format?
> qcow2 reports the real size regardless of the underlying storage, since
the allocations. However the size is reported in qemu-img check in the
$ dd if=/dev/zero bs=1M count=10 | tr "\0" "\1" > test.raw
$ truncate -s 200m test.raw
$ truncate -s 1g backing
$ sudo losetup -f backing --show
$ sudo qemu-img convert -f raw -O qcow2 test.raw /dev/loop2
$ sudo qemu-img info --output json /dev/loop2
$ sudo qemu-img check --output json /dev/loop2
We use this for reducing volumes to optimal size after merging snapshots,
we don't report this value to engine.
Is there a choice to create vm disk with format qcow2 instead of raw?
> Not for LUNs, only for images.
> The available formats in 4.3 are documented here:
> incremental means you checked the checkbox "Enable incremental backup"
> when creating a disk.
> But note that the fact that we will create qcow2 image is implementation
> detail and the behavior
> may change in the future. For example, qemu is expected to provide a way
> to do incremental
> backup with raw volumes, and in this case we may create a raw volume
> instead of qcow2 volume.
> (actually raw data volume and qcow2 metadata volume).
> If you want to control the disk format, the only way is via the REST API
> or SDK, where you can
> specify the format instead of allocation policy. However even if you
> specify the format in the SDK
> the system may chose to change the format when copying the disk to
> another storage type. For
> example if you copy qcow2/sparse image from block storage to file storage
> the system will create
> a raw/sparse image.
> If you desire to control the format both from the UI and REST API/SDK and
> ensure that the system
> will never change the selected format please file a bug explaining the
> use case.
> On 2/21/19 5:46 PM, Nir Soffer wrote:
>> On Thu, Feb 21, 2019, 21:48 <jingjie.jiang(a)oracle.com wrote:
>>> Based on oVirt 4.3.0, I have data domain from FC lun, then I create new
>>> vm on the disk from FC data domain.
>>> After VM was created. According to qemu-img info, the disk size is 0.
>>> # qemu-img info
>>> file format: raw
>>> virtual size: 10G (10737418240 bytes)
>>> disk size: 0
>>> I tried on iscsi and same result.
>>> Is the behaviour expected?
>> It is expected in a way. Disk size is the amount of storage actually
>> used, and block devices has no way to tell that.
>> oVirt report the size of the block device in this case, which is more
>> accurate than zero.
>> However the real size allocated on the undrelying storage is somewhere
>> between zero an device size, and depends on the imlementation of the
>> storage. Nither qemu-img nor oVirt can tell the real size.
>>> Users mailing list -- users(a)ovirt.org
>>> To unsubscribe send an email to users-leave(a)ovirt.org
>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
>>> oVirt Code of Conduct:
>>> List Archives: