7:14 p.m.
On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang <jingjie.jiang(a)oracle.com>
wrote:
What about qcow2 format?
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...
>