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

2019-03-13 Thread Nir Soffer 
On Wed, Mar 13, 2019 at 8:40 PM Jingjie Jiang 
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  wrote:
>
>> On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang 
>> 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 >>
 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

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

2019-03-13 Thread Jingjie Jiang 

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


On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang
mailto: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 mailto: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

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

2019-02-22 Thread Nir Soffer 
On Fri, Feb 22, 2019 at 7:14 PM Nir Soffer  wrote:

> On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang 
> 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 >
>>> 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/KSBETETRYBCP2H75EUZXK77RJWMTMQB6/

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

2019-02-22 Thread Nir Soffer 
On Fri, Feb 22, 2019 at 5:00 PM Jingjie Jiang 
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-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 
>> 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/NG62NX3ASV4WBVSTXZMNQK63GOZANFUU/

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

2019-02-22 Thread Jingjie Jiang 

Hi Nir,

Thanks for your reply.

What about qcow2 format?

Is there a choice  to create vm disk with format qcow2 instead of raw?


Thanks,

Jingjie


On 2/21/19 5:46 PM, Nir Soffer wrote:



On Thu, Feb 21, 2019, 21:48  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/OEWJQGCXOPB5EDAODL4JCWGXDWN7KOQ3/

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

2019-02-21 Thread Nir Soffer 
On Thu, Feb 21, 2019, 21:48  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/K7KHUEYV4PKDUDE5W635G5Q4IYT7Q4F4/