On Wed, Mar 13, 2019 at 8:40 PM Jingjie Jiang <jingjie.ji...@oracle.com> wrote:
> Hi Nir, > > I had qcow2 on FC, but qemu-img still showed size is 0. > > # qemu-img info > /rhev/data-center/mnt/blockSD/eaa6f641-6b36-4c1d-bf99-6ba77df3156f/images/38cdceea-45d9-4616-8eef-966acff2f7be/8a32c5af-f01f-48f4-9329-e173ad3483b1 > > image: > /rhev/data-center/mnt/blockSD/eaa6f641-6b36-4c1d-bf99-6ba77df3156f/images/38cdceea-45d9-4616-8eef-966acff2f7be/8a32c5af-f01f-48f4-9329-e173ad3483b1 > file format: qcow2 > virtual size: 20G (21474836480 bytes) > *disk size: 0* > cluster_size: 65536 > Format specific information: > compat: 1.1 > lazy refcounts: false > refcount bits: 16 > corrupt: false > > Is the behavior expected? > Yes, I explained it here on few weeks ago: http://lists.nongnu.org/archive/html/qemu-block/2019-02/msg01040.html > > Thanks, > > Jingjie > > > On 2/22/19 1:53 PM, Nir Soffer wrote: > > On Fri, Feb 22, 2019 at 7:14 PM Nir Soffer <nsof...@redhat.com> wrote: > >> On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang <jingjie.ji...@oracle.com> >> wrote: >> >>> What about qcow2 format? >>> >> qcow2 reports the real size regardless of the underlying storage, since > qcow2 manages > the allocations. However the size is reported in qemu-img check in the > image-end-offset. > > $ 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 > /dev/loop2 > > $ sudo qemu-img convert -f raw -O qcow2 test.raw /dev/loop2 > > $ sudo qemu-img info --output json /dev/loop2 > { > "virtual-size": 209715200, > "filename": "/dev/loop2", > "cluster-size": 65536, > "format": "qcow2", > "actual-size": 0, > "format-specific": { > "type": "qcow2", > "data": { > "compat": "1.1", > "lazy-refcounts": false, > "refcount-bits": 16, > "corrupt": false > } > }, > "dirty-flag": false > } > > $ sudo qemu-img check --output json /dev/loop2 > { > "image-end-offset": 10813440, > "total-clusters": 3200, > "check-errors": 0, > "allocated-clusters": 160, > "filename": "/dev/loop2", > "format": "qcow2" > } > > We use this for reducing volumes to optimal size after merging snapshots, > but > 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: >> >> https://ovirt.org/develop/release-management/features/storage/incremental-backup.html#disk-format >> >> 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.ji...@oracle.com wrote: >>> >>>> Hi, >>>> 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 >>>> /rhev/data-center/mnt/blockSD/eaa6f641-6b36-4c1d-bf99-6ba77df3156f/images/8d3b455b-1da4-49f3-ba57-8cda64aa9dc9/949fa315-3934-4038-85f2-08aec52c1e2b >>>> >>>> image: >>>> /rhev/data-center/mnt/blockSD/eaa6f641-6b36-4c1d-bf99-6ba77df3156f/images/8d3b455b-1da4-49f3-ba57-8cda64aa9dc9/949fa315-3934-4038-85f2-08aec52c1e2b >>>> 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. >>> >>> Nir >>> >>> >>>> Thanks, >>>> Jingjie >>>> >>>> _______________________________________________ >>>> Users mailing list -- users@ovirt.org >>>> To unsubscribe send an email to users-le...@ovirt.org >>>> Privacy Statement: https://www.ovirt.org/site/privacy-policy/ >>>> oVirt Code of Conduct: >>>> https://www.ovirt.org/community/about/community-guidelines/ >>>> List Archives: >>>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/TSXP7RENWIFMHIJWIAF6AGQPI3NOVNIZ/ >>>> >>>
_______________________________________________ Users mailing list -- users@ovirt.org To unsubscribe send an email to users-le...@ovirt.org Privacy Statement: https://www.ovirt.org/site/privacy-policy/ oVirt Code of Conduct: https://www.ovirt.org/community/about/community-guidelines/ List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/message/VARSBKRJPURMQ3HDQI6TCXRUGMGE24GL/
