On Fri, Feb 22, 2019 at 7:14 PM Nir Soffer <[email protected]> wrote:
> On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang <[email protected]> > 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 <[email protected] 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 -- [email protected] >>> To unsubscribe send an email to [email protected] >>> 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/[email protected]/message/TSXP7RENWIFMHIJWIAF6AGQPI3NOVNIZ/ >>> >>
_______________________________________________ Users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected]/message/KSBETETRYBCP2H75EUZXK77RJWMTMQB6/
