[ovirt-users] Re: qemu-img info showed iscsi/FC lun size 0

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?

Thanks, Jingjie 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&gt; wrote: > On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang <jingjie.jiang(a)oracle.com&gt; > 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... > > 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: >> >>> 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(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: >>> https://www.ovirt.org/community/about/community-guidelines/ >>> List Archives: >>> https://lists.ovirt.org/archives/list/users@ovirt.org/message/TSXP7RENWIF... >>> >>