|
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:
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:
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:
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
|