Bug 1526753

Moving back to NEW since attached patch has been abandoned

That's not a blocker for 4.2.1 (raw is OK, just slow to copy).
It depends on a missing implementation on Ansible - see https://github.com/ansible/ansible/issues/34091

I've deployed SHE ansible over Gluster on RHEL7.5 and seen these within the deployment log:
2018-02-19 20:23:39,014+0200 DEBUG otopi.ovirt_hosted_engine_setup.ansible_utils ansible_utils._process_output:94 qemu
_img_out: {'stderr_lines': [], u'changed': True, u'end': u'2018-02-19 20:23:38.476484', u'stdout': u'{\n    "virtual-s
ize": 53687091200,\n    "filename": "/var/tmp/localvmBvxW4T/images/44b5a089-6ce7-4a23-b4d1-b9dab3fe2687/5ef59632-5a32-
4285-95d9-54c59673e2f3",\n    "cluster-size": 65536,\n    "format": "qcow2",\n    "actual-size": 3142901760,\n    "for
mat-specific": {\n        "type": "qcow2",\n        "data": {\n            "compat": "1.1",\n            "lazy-refcoun
ts": false,\n            "refcount-bits": 16,\n            "corrupt": false\n        }\n    },\n    "dirty-flag": fals
e\n}', u'cmd': [u'qemu-img', u'info', u'--output=json', u'/var/tmp/localvmBvxW4T/images/44b5a089-6ce7-4a23-b4d1-b9dab3
fe2687/5ef59632-5a32-4285-95d9-54c59673e2f3'], 'failed': False, u'delta': u'0:00:00.173047', u'stderr': u'', u'rc': 0,
 'stdout_lines': [u'{', u'    "virtual-size": 53687091200,', u'    "filename": "/var/tmp/localvmBvxW4T/images/44b5a089
-6ce7-4a23-b4d1-b9dab3fe2687/5ef59632-5a32-4285-95d9-54c59673e2f3",', u'    "cluster-size": 65536,', u'    "format": "
qcow2",', u'    "actual-size": 3142901760,', u'    "format-specific": {', u'        "type": "qcow2",', u'        "data
": {', u'            "compat": "1.1",', u'            "lazy-refcounts": false,', u'            "refcount-bits": 16,', 
u'            "corrupt": false', u'        }', u'    },', u'    "dirty-flag": false', u'}'], u'start': u'2018-02-19 20
:23:38.303437'}

Deployment was made on these components:qcow2
rhvm-appliance-4.2-20180202.0.el7.noarch
ovirt-hosted-engine-ha-2.2.5-1.el7ev.noarch
ovirt-hosted-engine-setup-2.2.10-1.el7ev.noarch
Red Hat Enterprise Linux Server release 7.5 Beta (Maipo)
Linux 3.10.0-829.el7.x86_64 #1 SMP Tue Jan 9 23:06:01 EST 2018 x86_64 x86_64 x86_64 GNU/Linux

It looks like we're still using qcow2?

I've attached the ovirt-hosted-engine-setup-20180219201805-vvpxp8.log

Created attachment 1398003 [details]
deployment log

What do you see at the end, in oVirt?

(In reply to Nikolai Sednev from comment #3)
> "/var/tmp/localvmBvxW4T/images/44b5a089-6ce7-4a23-b4d1-b9dab3fe2687/5ef59632-
> 5a32-
> 4285-95d9-54c59673e2f3",\n    "cluster-size": 65536,\n    "format":
> "qcow2",\n    "actual-size": 3142901760,\n    "for

This is just the bootstrap VM on local storage.
We are converting to raw just at the end moving it to the shared storage.

(In reply to Yaniv Kaul from comment #5)
> What do you see at the end, in oVirt?

The image created on Gluster storage is raw sparse now.
I've tested it on Gluster, not NFS though, but the final result will be the same also for NFS, as both are files storage:
[root@alma04 ~]# qemu-img info /rhev/data-center/mnt/glusterSD/gluster01.scl.lab.tlv.redhat.com\:_nsednev__he__1/286227f5-1bf7-4463-9574-6c9c29c15f06/images/d1244b0a-8eaf-4fee-b643-9d6925d6e5b9/800336b0-9b8e-432d-95b0-301e613a4d82
image: /rhev/data-center/mnt/glusterSD/gluster01.scl.lab.tlv.redhat.com:_nsednev__he__1/286227f5-1bf7-4463-9574-6c9c29c15f06/images/d1244b0a-8eaf-4fee-b643-9d6925d6e5b9/800336b0-9b8e-432d-95b0-301e613a4d82
file format: raw
virtual size: 50G (53687091200 bytes)
disk size: 3.1G

I would like to move this bug to verified, although NFS deployment currently blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1540107 and I'll have to wait until it fixed, to verify on NFS storage.

(In reply to Nikolai Sednev from comment #7)
> (In reply to Yaniv Kaul from comment #5)
> > What do you see at the end, in oVirt?
> 
> The image created on Gluster storage is raw sparse now.

Excellent, thanks.

> I've tested it on Gluster, not NFS though, but the final result will be the
> same also for NFS, as both are files storage:
> [root@alma04 ~]# qemu-img info
> /rhev/data-center/mnt/glusterSD/gluster01.scl.lab.tlv.redhat.com\:
> _nsednev__he__1/286227f5-1bf7-4463-9574-6c9c29c15f06/images/d1244b0a-8eaf-
> 4fee-b643-9d6925d6e5b9/800336b0-9b8e-432d-95b0-301e613a4d82
> image:
> /rhev/data-center/mnt/glusterSD/gluster01.scl.lab.tlv.redhat.com:
> _nsednev__he__1/286227f5-1bf7-4463-9574-6c9c29c15f06/images/d1244b0a-8eaf-
> 4fee-b643-9d6925d6e5b9/800336b0-9b8e-432d-95b0-301e613a4d82
> file format: raw
> virtual size: 50G (53687091200 bytes)
> disk size: 3.1G
> 
> I would like to move this bug to verified, although NFS deployment currently
> blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1540107 and I'll have
> to wait until it fixed, to verify on NFS storage.

On NFSv4.2 might be sparse as well, but in any case, RAW.
Thanks,
Y.

Works for me on NFS deployment on these components:
ovirt-hosted-engine-ha-2.2.5-1.el7ev.noarch
ovirt-hosted-engine-setup-2.2.10-1.el7ev.noarch
rhvm-appliance-4.2-20180202.0.el7.noarch
Linux 3.10.0-851.el7.x86_64 #1 SMP Mon Feb 12 07:53:52 EST 2018 x86_64 x86_64 x86_64 GNU/Linux
Red Hat Enterprise Linux Server release 7.5 Beta (Maipo)

The image created on NFS storage is raw sparse now.
alma04 ~]# qemu-img info /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Compute__NFS_nsednev__he__2/8d035e7b-13b0-4782-a99d-3c8ffaffdd4f/images/aa112408-1c01-405c-82b9-20e06dcaca1f/09e8ac4b-573a-4b1d-aba0-c0e2168f04de
image: /rhev/data-center/mnt/yellow-vdsb.qa.lab.tlv.redhat.com:_Compute__NFS_nsednev__he__2/8d035e7b-13b0-4782-a99d-3c8ffaffdd4f/images/aa112408-1c01-405c-82b9-20e06dcaca1f/09e8ac4b-573a-4b1d-aba0-c0e2168f04de
file format: raw
virtual size: 50G (53687091200 bytes)
disk size: 3.1G

This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018.

Since the problem described in this bug report should be
resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.