Description of problem: The copy to storage command on NFS creates a qcow2 disk image, instead of raw-sparse: Dec 16 15:06:42 lago-he-basic-suite-master-host0 python: ansible-command Invoked with warn=True executable=None _uses_shell=False _raw_params=qemu-img convert -n -O qcow2 /var/tmp/localvm/images/f8a0f3c4-9133-41aa-bda7-2680f933bc52/577bb119-1c60-4f9f-8ff5-9d06896f4ce1 /rhev/data-center/mnt/lago-he-basic-suite-master-storage:_exports_nfs__he/d8fd6a3c-f736-4e74-9854-538499d564ad/images/69788ea3-1431-4099-aec9-b39fc3fa255c/0e7f6fa3-352c-43bf-972a-c1746e977e95 removes=None creates=None chdir=None stdin=None It should create a raw sparse. Optionally, with '-o preallocation=falloc' to fallocate the file on the NFS server. But it certainly should not use qcow2. You can use '-S sparse_size' (default 4K according to man) to get sparse allocation.
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.